wasmtime: Cache VMFuncRef in component::Func

[adamrk]

A core Func caches a raw pointer to its VMFuncRef, but a
component::Func rederives the pointer on ever call and this
contributes to host -> wasm component function calls having
significantly higher overhead than core function calls (even concurrency
support disabled).

This PR caches the VMFuncRef for component::Func in the same it is
currently done for core Func. The VMFuncRef for the associated
post_return call is also cached along with Some additional metadata.

These are my benchmark results for the impact on nop calls with no
arguments or return values:

Before change:

| Call type                         | Latency |
-----------------------------------------------
| core                              |   35 ns |
| component (concurrency disabled)  |  300 ns |
| component (concurrency enabled)   |  800 ns |

After change:

| Call type                         | Latency |
-----------------------------------------------
| core                              |   35 ns |
| component (concurrency disabled)  |  140 ns |
| component (concurrency enabled)   |  600 ns |

The bencmarks run are:

cargo bench --bench call -- --exact "sync/no-hook/core - host-to-wasm - typed - nop"
cargo bench --bench call -- --exact "no-concurrent/sync/no-hook/component - host-to-wasm - typed - nop"
cargo bench --bench call -- --exact "concurrent/sync/no-hook/component - host-to-wasm - typed - nop"

A separate commit also modifies the call benchmark to allow running component calls without concurrency support.

[adamrk]

Note: This change to the benchmark was required to bench component calls with concurrency_support disabled. The previous setup would only run them with it enabled.

[adamrk]

Note: I think we could also save a lookup here by caching CanonicalOptions as well, but I didn't do it because that type has a bunch of fields and variants which I think would require either

1. Making the C type messy and changing it whenever new canon opts are made. Or
2. Boxing CanonicalOptions before storing it in Func.

[alexcrichton]

Nice wins! Do you have a relative breakdown of where the wins are coming from? For example which lookup is the most expensive?

I'm a bit wary to inflate component::Func too too much to avoid duplicating information thoughout the runtime, so if some of the field movements are pretty minor in wins and one field predominantly dominates that might be a way to cut down on duplication. Naively for example I'd expect that ExportIndex would be relatively quick to lookup the type/options, and then the presence of post-return and async-ness in theory not too much more expensive when looking up the options themselves. Basically I'd expect that the unsafe_func_ref field to be the majority of the win here, but before actually changing anything here I'd want to confirm about where the performance wins come from

[adamrk]

Do you have a relative breakdown of where the wins are coming from? For example which lookup is the most expensive?

I didn't do a breakdown, but I can get one. Also I'm now realizing that abi_info gets called a few times, so maybe even if we don't include other fields in Func we can at least get some improvement by just calling abi_info once and reusing the result.

[adamrk]

For the case of concurrency disabled, with just the unsafe_func_ref field I'm seeing a time of 180ns (from the 300ns original). So all the other fields together are an additional ~40ns. It's a bit hard to divide up the remaining amount between specific other fields because I'm seeing 10-20ns swings between runs anyway.

I also realized we could mostly reuse the results of abi_info in the non-concurrent case without caching them in Func and that seems to give us most of the benefits anyway. With the existing changes I'm now seeing 140ns with concurrency disabled (same as the original change) and 730ns with concurrency enabled (not as big as the original change).

I guess this means we could just use the unsafe_func_ref field and there's probably opportunity to improve the concurrent case as a follow up by reusing the results of abi_info more.

[alexcrichton]

Sounds reasonable to me, and changes look good!