Speed up getting and setting funcref elements/fields in GC objects

[fitzgen]

We don't keep VMFuncRef pointers inside the GC heap, as the GC heap is untrusted, and instead have a side table, and store table IDs in GC objects. We currently use libcalls to do id-to-funcref conversion when reading a funcref out from a GC object and to intern a funcref and get its associated table ID when writing the funcref into a GC object. libcalls on field/element access are very much not ideal from a performance perspective.

I wrote up some thoughts on how we could improve the situation in the original PR:

My most-immediate thoughts are that we would do roughly the following to speed this up:

• Expose the slab to Wasm, allowing id-to-funcref conversion to happen fully within wasm code
• for funcref-to-id conversion, add an LRU/associative cache to the vmctx (or maybe runtime limits) to cache the results of the libcall and allow the happy path to stay within wasm code. the slow path would still fall back to a libcall however (I do not want to implement hashing in wasm code and try to keep it in sync with the Rust hashing)

My hope is that the above would result in good enough perf for us to not have to revisit this for quite a while.

Originally posted by @fitzgen in https://github.com/bytecodealliance/wasmtime/issues/9341#issuecomment-2386456719