Move game logic/rendering to another thread

[philpax]

At present, the top-level UI world and the game world that it's presenting (through GameClientView) live on the same thread. This means that performance issues in the game world will stall the top-level UI as well, making the debugger and any other UI we might offer at this layer (performance tooling, etc) unresponsive.

We may be able to address this by moving the entirety of the game world and its rendering to another thread, so that the game world can run over-budget without impacting the surrounding tooling. The game thread would receive input from the outside world (user input, what to connect to, etc) and output to a render target, which the main thread's UI will then render.

There are a few caveats here, thought:

• This only helps with Ambient system UI, like the debugger. It won't fix Music sequencer example: Unnecessary UI rerendering #380, as that UI lives entirely within the guest. It also means that the control UI for a performance benchmark will still break down.
• It will require Use WebWorker to handle WebTransport connection #1177 on native as well - the networking stack needs to be able to handle the game logic not running on the main thread, and the work for Use WebWorker to handle WebTransport connection #1177 is likely to come into play for this.
• The debugger will still need to view the ECS from the game thread, and that view needs to be consistent (i.e. no partial-updates). This implies some form of synchronization and/or copying of the relevant state from the game thread to the main thread.
  • If it's dealing with a copy, does that mean the debugger can't mutate the game world?
• At present, the code assumes that the UI world always has access to the game world. We will need to seek out these assumptions and remove or replace them - the two worlds should never meet, except at pre-arranged points of synchronization.
• The UI world needs to ensure that it only renders complete frames from the game world, and never attempts to render a partial frame. This should be easy to do with double-buffering and some synchronization.
• There are a few open questions about how this would work on the web.
  • Our current thinking is that it's possible to set up a shared memory buffer between the main thread and a webworker, and treat that as a raw memory buffer that's mapped into the address space of the relevant WASM instances. However, how complex are the structures we can share in this buffer? Can we have pointers? Will we need to serialize/deserialize in and out of it?
  • How do we share complex resources between the main thread and the game thread? What happens if they need to share the same WebGPU device and queue? Or, for that matter, the WebGPU render target that the game is rendering to?
  • Can we ensure the abstractions we build for this work for both native (where you can just use threads and easily share resources) and web (where the main thread and workers are much more clearly delineated, and support for complex shared memory interactions is limited?)