Update crate to WASIp3 preview bindings

[alexcrichton]

This is a proof-of-concept, not currently working, of upgrading this crate to WASIp3. The various changes here are:

• Existing main has been branched to release-0.14.x for future development/releases.
• Here WITs are updated to the latest WASIp3 snapshot.
• The crate's version now has an "rc" in it which matches the WASIp3 "rc".
• Rust stable is temporarily removed from testing because async support hasn't landed there yet.
• CI versions of Wasmtime/wasm-tools are updated to support async.
• The split in examples of std/not-std is all removed. The WASIp3 version currently has no support for no_std, so everything is always std. Additionally there is no longer integration with std::io objects for WASIp3.
• Dep-of-std support is removed while no_std is not yet implemented.

[alexcrichton]

This is a draft for now due to a few outstanding items:

• Need to figure out how to get the targets tests in CI working again. One requirement is Enable all features in targets subcommand wasm-tools#2290 but another is that it's going to have to allow WASIp2 imports for now, for example.
• Should probably re-add tests for componentization of wasm32-unknown-unknown to double-check that WASIp2 imports aren't present.
• Wasmtime does not have a release where the release binaries have component-model-async support
• Wit-bindgen needs Redefine with in the Rust generator to only apply to imports wit-bindgen#1367
• The README needs a likely heavy amount of updating.
• The crate documentation likely needs a lot of similar updating.
• Probably worth spending a moment considering the examples if we could do better in terms of low-level APIs.

[sunfishcode]

Is the "std" feature something that could be re-introduced in the future, or is there a fundamental conflict?

Rust's own std depends on wasi with the std feature disabled. That code is still using the p1-style API, but in the future would make sense to update to p3. We don't need to do anything here and now; I'm just trying to understand how things will fit together in the future.

[alexcrichton]

Yeah updating it to have gated "std" features should be possible, just some work that hasn't happened yet. Rust doesn't currently depend on WASIp2 yet (the 0.14 track) so that'll probably be the first jump before going to WASIp3.

But yeah basically my gut is saying that we should skip no_std support for now and deal with that when libstd wants to integrate this. At the same time we'd probably want to bind blocking-style APIs for streams/futures and those would be the ones supported in no_std mode.

[alexcrichton]

Ok this is now a final version of this PR suitable for review-to-merge. This is built on #118 currently and mirrors the organization there for WASIp2.