`call_async` performance regression with `component-model-async` feature enabled

#11127 changes the implementation of `[Typed]Func::call_async` when the `component-model-async` feature is enabled, conservatively setting up the state required to handle the Component Model async ABI in case the guest function uses it. This extra work shows up in microbenchmarks such as `async-pool/no-hook/component - host-to-wasm - typed - nop-params-and-results`, where we see a 120%-150% regression vs. the original code path.

Alex and I spent some time looking at the profile, and there was no obvious low-hanging fruit. The main hotspots appear to be moving large objects in memory, possibly related to `wasmtime::runtime::component::concurrent::GuestTask` and `Future`s containing it.

We should try to improve the existing `async-pool/no-hook/component - host-to-wasm - typed - .*` benchmarks and also add new ones which actually exercise the async ABI features (e.g. an async-with-callback-lifted export which yields N times before completing).