Change how components interact with the pooling instance allocator

[alexcrichton]

Currently the implementation of components in Wasmtime is naively integrated with core wasm, meaning that when using the pooling allocator each core wasm instance as part of a component will take up a separate slot on the pooling instance allocator. This goes against the high-level design of the pooling instance allocator and application design, however, where an "instance" typically corresponds to one slot and the resources in that slot are what's available for that single instance.

Instead I think a few changes to resource accounting should be made:

• Components should allocate a single VMContext + VMComponentContext "smashed together" block. Wasmtime can statically identify how many core wasm instances are needed and calculate the total size needed to allocate all contexts together. Alternatively each VMContext and VMComponentContext should be allocated separately from within a single slot after a slot is reserved for the component. Either way, a single slot in the instance pool should correspond to the entire component instance.
• Tables should also be updated to draw from one slot in the table pool. Currently most tables are not actually growable in core wasm which means that a component can leverage this and statically allocate tables where non-growable ones come first in a slot and an optional final growable table is at the end. This should suffice for function tables for now and futher options could be implemented in the future as necessary. Like the instance data, though, all table allocations should go through a single slot rather than optionally taking up multiple slots per component instance.
• Linear memories, however, will need to stay as-is. This means that, by default, a component will only be able to have one linear memory for the near future (unless the pooling allocator gives multiple linear memories to each slot). These are more tricky due to the address space reservation requirements so it's less obvious how to smash distinct allocations together from within a component.

Overall the component instantiation process, when using the pooling instance allocator, will need to be significantly refactored to ensure that instantiation of a component will work with only one pooling allocator slot rather than the multiple that happens today with one per core wasm instance.

[alexcrichton]

Addressed in #6835