Wasm runtime performance tracking issue

[ten3roberts]

When switching to wasm_component_layer and wasm_runtime_layer we will get the wasmtime/web abstraction for free, as well as the very gnarly component parsing, which was previously done by either wasmtime_component or jco.

However, as there is no such thing as a free lunch, there are additional things we will need to do.

• Implement the web backend for wasm_runtime_layer (and maybe wasm_component_layer) Wasm web runtime performance #1131
• Implement the wit_bindgen macro for wasm_component_layer to integrate with its linker wit_bindgen! macro DouglasDwyer/wasm_component_layer#4
• Fully covered, but mostly stubbed wasi implementation for wasm_component_layer. This will be easier than the wasi in wasm-bridge as we can use the wit_bindgen macro for the glue, rather than doing it manually in the crate as before.
• Modify Ambient to use wasm_component_layer with appropriate runtime selection instead of wasmtime or wasm-bridge directly with cfg guards.
• Write a guest package which tests the performance, and measure before and after to get proper hard figures of the improvements.

In addition to this, there are further smaller improvements we can make in the new implementation to squeeze more performance:

Though before any of these are started, we need to do the above and measure to validate that they have improved performance from the wasm_component_layer baseline.

• Use generics and traits over value-enums for VM data
• String interning for the few lookups that will remain
• Async module compilation and instantiation
• Slimmer ECS component representation (Ambient only). We currently use a gigantic enum which is at large as the largest member, which is a Mat4, so a u8 requires as much bandwidth as Mat4
• Minimize busy polling in our naïve guest side executor
• Use more string interning for reflection and other lookups

Tagging you @philpax just to make sure you see this :)

Originally posted by @ten3roberts in #1131 (comment)