Functions defined with `wrap_async` and various variants "block" the store from making progress on concurrent tasks

[alexcrichton]

This issue is similar to #11869 but I've separated it out to specifically deal with usage of block_on with respect to wrap_async and its variants. The wrap_async function has been a pillar of Wasmtime's async support historically but it's effectively entirely incompatible with component-model-async semantics. Notably wrap_async "locks" a store across await points meaning that it's not possible to progress other tasks at the same time. While this sort of means that wrap_async is "just another blocking call" from the perspective of a component it has the notable consequence of making run_concurrent not actually properly run things concurrently. Effectively this suffers from the same problems as #11869.

Fixing this issue is expected to be difficult. Ideally we'd "just delete all calls and use wrap_concurrent instead", but that's a pretty large change to make. That also doesn't clearly translate to core wasm where there's no equivalent of concurrent calls at this time. A more localized fix would be to remove all of Wasmtime's usage of wrap_async, document the pitfalls, and then move on. For example wasmtime-wasi would avoid using wrap_async and would use wrap_concurrent (or an equivalent thereof) instead. This wouldn't actually fix WASIp1 APIs since there's no *_concurrent available, though.

Regardless I wanted to write down this issue to have a place to discuss this and notably link to in the source/documentation about how this is a major limitation of run_concurrent today.