[WIP] Implement Pthread Manager Worker for synchronous thread creation

[sbc100]

[WIP] - Gemini Created initial PR

This change introduces a dedicated 'Pthread Manager' worker that acts as an intermediary for managing the lifecycle of pthread workers.

By moving the responsibility of spawning and managing workers to a dedicated manager worker, we enable synchronous pthread creation on the main browser thread even when it is blocked (e.g. during a join or futex wait). This is because the manager worker and its nested child workers can be started by the browser independently of the main thread's event loop.

Key changes:

• Add PTHREAD_MANAGER setting to enable this new mode.
• Update shell.js and parseTools.mjs to detect and support the manager environment.
• Update libpthread.js to spawn the manager worker and proxy thread creation requests to it.
• Update runtime_pthread.js with logic to handle the manager worker's responsibilities: spawning, terminating, and relaying messages for child pthreads.
• Ensure the manager worker is fully initialized before the main application starts using addRunDependency.

Fixes: #18633

[sbc100]

I had gemini create this. @juj @tlively @dschuff WDYT? Is this is reasonable approach? One thing I'm not sure about is whether we want to re-use the ensure JS file in the worker-mananger so just run a tiny bit of custom JS there.

[sbc100]

Kind of an interesting approach that gemini took here, which is to create to have the pthread-manager running the same JS file.

I think this has some advantages in that we can keep the worker spawning code in place where it can run both in manager and non-manager mode.

I also like that avoids adding an additional file (e.g. manager.js) which I think would be non-starter.

The alternative would be to embed some kind of manager.js as a blob inside the main JS. But that could make it hard to maintain both modes simultaneously.

[juj]

By moving the responsibility of spawning and managing workers to a dedicated manager worker, we enable synchronous pthread creation on the main browser thread even when it is blocked

I don't think there is a web standard that guarantees this. It is arbitrary and unspecified whether a particular browser requires the calling Worker to periodically yield, or the main thread to periodically yield, in order to make progress on launching Workers.

If we do have this guarantee, I think we should first probe the W3C people to ensure that this will be enforced, and that it does actually work out in practice today in all the browsers.