Feature/web worker

[yush-1018]

This is a Draft PR implementing the foundation for the Web Worker API (Worker class) in boa_runtime.

What this PR does

1. Adds a new worker module in core/runtime/src/worker/
2. new Worker("script.js") spawns a fresh OS thread with its own Context and runs the given script file
3. worker.postMessage(msg) sends a string message to the worker thread using Rust's mpsc channels
4. worker.terminate() is stubbed out for now
5. Registered as a WorkerExtension in the runtime, so it's available out of the box
6. Added a basic smoke test

What's missing (and where I'd love some guidance )
This is intentionally a Draft — I wanted to get the architecture right before going further. A few things I'm unsure about:

1. Worker → Main thread messaging — How should onmessage work on the main thread side? Should we poll via run_jobs(), or is there a plan for a proper event loop in boa_runtime?
2. Structured Clone vs simple JSON — Right now I'm only sending strings. Should I go for full Structured Clone, or is a JSON-based approach fine as a starting point?
3. Worker global scope — The worker's Context is pretty bare right now (no console, setTimeout, etc.). What's the best way to bootstrap a DedicatedWorkerGlobalScope without creating circular deps with boa_runtime?
4. terminate() — Should I use engine interrupts to actually kill the worker thread?

Happy to iterate on any of this based on your feedback. Thanks for your time! 😊

[jedel1043]

To answer your questions:

Worker → Main thread messaging — How should onmessage work on the main thread side? Should we poll via run_jobs(), or is there a plan for a proper event loop in boa_runtime?

Since Boa supports enqueueing Rust futures, maybe we could kind of handwave this by enqueueing an async job that waits for messages from the workers? We could have some kind of Channel trait (or find a crate that has this) such that implementors can pick their optimal channel depending on which async executor they're using.

Structured Clone vs simple JSON — Right now I'm only sending strings. Should I go for full Structured Clone, or is a JSON-based approach fine as a starting point?

IMO starting with JSON is fine, but I think we kind of already support transferring objects using the boa_runtime::store module.

Worker global scope — The worker's Context is pretty bare right now (no console, setTimeout, etc.). What's the best way to bootstrap a DedicatedWorkerGlobalScope without creating circular deps with boa_runtime?

Huh? I don't think you need to worry about circular deps, right? Everything inside boa_runtime is importable from any module within boa_runtime, so you should be able to use the usual register and init methods.

terminate() — Should I use engine interrupts to actually kill the worker thread?

That's a good question... We currently don't have a way to interrupt engine execution unfortunately. The best thing we have is evaluate_async which does yield to an async executor after a certain amount of VM instructions happened, but it doesn't capture things like inner calls to Context::run so it's not that reliable TBH.

If we want to support killing a worker thread, we might have to create something akin to a cancellation handle for the Context.