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

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.