Run Blazor WebAssembly in a Web Worker

It will be a while before we get to this, but various parts of the architecture are already designed with this in mind.

We should support running Blazor in two modes, auto-selecting which one is best for the current user's browser:

* **On the browser's main JS thread**, which is necessary for older browsers that don't support WebWorker. The .NET/JS interop can continue using shared memory if we find it's necessary to have good perf on those older browsers (and thread safety is not difficult because it's all synchronous).
* **In a web worker (background thread) on more up-to-date browsers**. The .NET/JS interop will need to work by serializing any data that is being transferred rather than passing pointers [1].

This will be advantageous because then, even if your .NET code does something that locks up the CPU (such as a GC cycle), the UI will remain perfectly smooth (e.g., during animations or scrolling, or while the user is typing quickly into a textbox).

The existing UI update mechanism is designed around transferring batches of minimal diffs from .NET to JS, so it shouldn't be hugely difficult to have it express those diffs as serialized data rather than pointers into the WASM memory space. We'll have to be careful around things like event handling to ensure that the asynchrony can't result in inconsistency of behaviour versus the synchronous single-threaded model. For example, we will need to force all event delivery to be async as far as the JS side is concerned, even in the non-worker-thread case.

*[1] Strictly speaking, we could also do it with shared memory on even newer browsers that support SharedArrayBuffer. But if we can get satisfactory perf without this, it would be better to serialize because it would mean fewer combinations of browser scenarios, and saves us having to deal with potentially complex thread-safety concerns on the .NET side.*