Support Resource<T> -> ResourceAny for WASI resources

[rvolosatovs]

Feature

With #7688 implemented it is now possible to take Resource<T> to ResourceAny, however the conversion does not work for resources provided by wasmtime_wasi crate, since the ResourceImportIndex is not exposed to the developer for those resources.

This is particularly important for dynamically-defined functions defined via Linker::func_new, which operate on wasmtime::Val directly. For example, it is currently not possible to return a wasi:io/poll/pollable resource from such a function without defining a custom wasi:io/poll/pollable implementation in the linker to acquire the import index to pass to try_into_resource_any in order to convert it to ResourceAny

Benefit

This allows dymanically-typed function definitions to operate on resources provided by WASI, i.e. it removes the need for developers using dynamically-typed functions utilizing WASI resources from reimplementing (parts of) WASI

Implementation

Since lookups by string import paths were considered too slow for #7688, it appears that the only alternative would be adapting wit-bindgen (e.g

wasmtime/crates/wit-bindgen/src/lib.rs

Line 810 in 61e1cdf

"linker.resource(

) to capture the indexes returned by LinkerInstance::resource calls in a table of some sorts returned by add_to_linker, if we still want to avoid the string lookups, that could be a nested struct type, where an index lookup could look something like this:

let idx = resource_definitions.wasi.io.poll.pollable

Alternatives

Allow string lookups for the RuntimeImportIndex as an alternative to the ResourceImportIndex computed at LinkerInstance::resource

[alexcrichton]

I like the idea of the generated add_to_linker function returning a typed structure with *Index items inside of it myself. That seems like a nicely declarative route of communicating the result of all the add_to_linker calls.