feat(go-sdk): add wasi hostcalls used by the Go SDK

[leonm1]

The full Go sdk imports hostcalls not currently exported to the wasm module, making the wasm module fail on instantiation. Per discussion with the Go core maintainers, these functions do not need to be implemented, but they must be present.

[PiotrSikora]

Thanks for working on this!

Two high-level comments:

1. It would be good to understand why Go SDK wants to import (and use?) those hostcalls. For filesystem calls - does it try to access some files on startup, and why it doesn't use preopen hostcalls? For yield and polling - does it actually work without making progress or are non-trivial plugins going to deadlock?
2. Since we're exposing those hostcalls globally, how does it affect other the SDKs? If you try to open files in Rust or C++ files, will they gracefully return user errors (i.e. file not found or similar) or crash due to a missing code path for ENOSYS?

[leonm1]

1. It would be good to understand why Go SDK wants to import (and use?) those hostcalls. For filesystem calls - does it try to access some files on startup, and why it doesn't use preopen hostcalls?

Answered elsewhere as well, but I was mistaken about some of the filesystem syscalls. This PR now represents the full minimal set of added hostcalls for a helloworld go plugin to initialize.

For yield and polling - does it actually work without making progress or are non-trivial plugins going to deadlock?

Yield should be fine due to the linked behavior. For polling, I do wonder about that — technically we could support some of the subscription types, but I'm not sure how much value they add in a single-threaded environment anyway, since we only support FDs 1 and 2, which never get "closed" and wouldn't "block" from the wasm modules perspective.

2. Since we're exposing those hostcalls globally, how does it affect other the SDKs? If you try to open files in Rust or C++ files, will they gracefully return user errors (i.e. file not found or similar) or crash due to a missing code path for ENOSYS?

I tested the CPP host with all of service extensions' cpp and rust plugins. Since these are added hostcalls, they should not affect currently-working wasm modules. I attempted to add explicit calls to each of sched_yield, poll, and fdstat_set_flags (which corresponds to posix's fcntl), and confirmed each translated the libc call to the corresponding wasi hostcall and none complained about the ENOSYS (or ESUCCESS, in sched_yield's case).

[PiotrSikora]

Since these are added hostcalls, they should not affect currently-working wasm modules.

Right, this won't break any of the existing plugins. My point was mostly that with those changes (well, the earlier version of this PR) plugins that attempt to open files would load successfully, but could break at runtime.

[PiotrSikora]

Thanks!

[martijneken]

LGTM, thanks!

[mpwarres]

LGTM, thanks!