wasmtime-wasi: Split a new IoView trait off of WasiView

[pchickey]

This PR prepares the wasi-io aspects of the wasmtime-wasi crate to be split off into its own independent crate, in order for the common base of wasi-io functionality to be reusable in a variety of host implementations which do not intend to reuse all of wasmtime-wasi.

Summary for users

You're an embedder using wasmtime-wasi, and maybe even wasmtime-wasi-http. You defined a struct like:

use wasmtime::component::ResourceTable;
use wasmtime_wasi::WasiCtx;
use wasmtime_wasi_http::WasiHttpCtx;
struct MyCtx {
    table: ResourceTable,
    wasi: WasiCtx,
    http: WasiHttpCtx,
}

Prior to this PR, you'd hook your MyCtx up to the WasiView and WasiHttpView traits like:

impl WasiView for MyCtx {
    fn table(&mut self) -> &mut ResourceTable { &mut self.table }
    fn ctx(&mut self) -> &mut WasiCtx { &mut self.wasi }
}
impl WasiHttpView for MyCtx {
    fn table(&mut self) -> &mut ResourceTable { &mut self.table }
    fn ctx(&mut self) -> &mut WasiHttpCtx { &mut self.http }
}

After this PR, you rewrite that to:

impl IoView for MyCtx {
    fn table(&mut self) -> &mut ResourceTable { &mut self.table }
}
impl WasiView for MyCtx {
    fn ctx(&mut self) -> &mut WasiCtx { &mut self.wasi }
}
impl WasiHttpView for MyCtx {
    fn ctx(&mut self) -> &mut WasiHttpCtx { &mut self.http }
}

Thats it. For almost all users, you don't have to worry about anything else. All of the other aspects of wasmtime_wasi{,_http}::add_to_linker_{sync,async} keep working exactly like before. Semantically, nothing changed. The WasiView and WasiHttpView traits grew a common implies on the IoView trait, i.e. trait WasiView: IoView {...}, trait WasiHttpView: IoView {...}.

More details

You probably don't care about these, unless you are doing low level linker stuff and probably can just read the source code to figure it out.

There's a new IoImpl struct that the wasi-io Host trait impls, instead of WasiImpl. Like WasiImpl this struct is #[repr(transparent)]. Anytime you were constructing a WasiImpl(t), you now construct WasiImpl(IoImpl(t)), e.g. https://github.com/bytecodealliance/wasmtime/pull/10016/files#diff-a6ec073ba5d074b65f0bcbf8df48af2b126d65034398905bf74d8f10a5c5f8b6R288

If you're using the wasmtime-wit-bindgen generated add_to_linker_ funcs directly, you'll need a variant on the type_annotate hack to get rustc to infer IoView in the right places, e.g. https://github.com/bytecodealliance/wasmtime/pull/10016/files#diff-a6ec073ba5d074b65f0bcbf8df48af2b126d65034398905bf74d8f10a5c5f8b6R287.

[alexcrichton]

These docs are now appended to the ones above, so should these words move above the example perhaps?

[pchickey]

I made lots of fixes to the docs during the code motion for #10036 - can we put off the docs review and check it all over there?

[alexcrichton]

Sounds reasonable to me 👍

[alexcrichton]

Could this retain some of the documentation from before as well? Ideally with an example or links to other examples throughout the crate.

[alexcrichton]

To perhaps bikeshed a bit, maybe TableView?

[alexcrichton]

Also mind ensuring there's documentation for this trait as well? (similar to the WasiView one below)

[pchickey]

I named it Io instead of Table view in anticipation of factoring it out for the wasmtime-wasi-io crate. I don't mind renaming it, but thats why I was thinking Io over Table.