Run Emscripten RestClient fetches on a worker thread

[drslebedev]

Emscripten delivers fetch callbacks on the thread that issued the request,
after that thread returns to the JS event loop. ClientContext worked around
this by starting a std::thread for every command and immediately joining it,
blocking its poller. Direct RestClient users such as OpenDigitizer had no
workaround, so fetch callbacks could run on the browser main thread.

Give each Emscripten RestClient a persistent worker and route requests, long
polling, unsubscribe and cleanup through it. Resume a 504 long-poll timeout
at the same index instead of ending the subscription.

Fetch completion and subscription callbacks now run on the REST worker, so
consumers must synchronise shared state. Each active client uses one worker,
which is reclaimed asynchronously during shutdown.

Remove the per-request thread workaround from ClientContext. The native
RestClient implementation is unchanged.

Add an Emscripten integration test covering subscriptions, unsubscribe,
shutdown, callback threading and worker reclamation. The Node test requires
the xhr2 npm package. Browser tests are registered when emrun and a matching
browser are available; OPENCMW_REQUIRE_BROWSER_TESTS requires at least one
browser test.

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[RalphSteinhagen]

Great addition to the unit-test suites and thanks a lot for the WASM-worker changes of the REST Clients. That should resolve a lot of the CPU and network contention, eliminate dropping of data in high network load conditions, and alleviate the CPU performance issues.

The data point reduction algorithm you indicated would be a further improvement but I'd rather de-prioritize this in favour of tackling the issue at the source (i.e. ImPlot/ImGUI itself).