Modularize the WASI API.

[sunfishcode]

This splits what was once wasi_unstable into separate modules. There's
a lot of API evolution still to be done here, and the groupings
presented here may change, but this should help get things started.

This is currently a draft PR not yet suitable to merge, but suitable to discuss :-).

[sunfishcode]

Ok, this is now updated and rebased, and I believe it's ready to go.

[leonwanghui]

@sunfishcode I think it's a great work, but I have a little quesition that how can we update the minimal code if we update the tag from emphemeral to snapshot. From the current change, it would take a lot of modification.

[sunfishcode]

@leonwanghui For most users of WASI, the answer is to avoid calling WASI APIs directly, and use WASI libc, Rust's libstd, AssemblyScript, or other toolchains that provide stable and higher-level APIs on top of it. For maintainers of these toolchains, and for maintainers of WASI implementations, using witx generators to generate boilerplate code can reduce the amount of work you need to do when the API changes.

That said, I recognize that this PR will likely still require a lot of work for some people. I'd be interested in hearing any ideas about how we could make this easier. As a maintainer of both an implementation of WASI and of toolchains for WASI, this will be a lot of work for me too. There's been some exploration about auto-generating polyfills, for example.

Concerning this PR in particular, modularization is one of the most-requested changes in WASI, and it's a requirement for many other things we want to do, and we have consensus here, so I'm going to proceed with the change. But if there are ways we can help, please let us know!