Enable emscripten_futex API for Wasm Workers

[sbc100]

This involves also including emscripten_thread_state.S which provides
APIs such as emscripten_is_main_runtime_thread and
emscripten_is_main_browser_thread` which now also work in Wasm Workers.

There is a minor code size hit here of ~80 bytes, but I think its
worth it to have these low level APIs available everywhere.

Depends on: #26309
Fixes: #26314

[sbc100]

Can you also take a look at #26309 which this change depends on ?

[juj]

There is a minor code size hit here of ~80 bytes, but I think its
worth it to have these low level APIs available everywhere.

Maybe a better approach would be to implement emscripten_futex_wait/wake in terms of emscripten_atomic_wait_u32() and emscripten_atomic_notify() without bringing the overhead? The overhead here is about POSIX emulation, and avoiding that was exactly why Wasm Workers exists.

[sbc100]

There is a minor code size hit here of ~80 bytes, but I think its
worth it to have these low level APIs available everywhere.

Maybe a better approach would be to implement emscripten_futex_wait/wake in terms of emscripten_atomic_wait_u32() and emscripten_atomic_notify() without bringing the overhead? The overhead here is about POSIX emulation, and avoiding that was exactly why Wasm Workers exists.

I think they overhead is more about being able to run on the main thread.

emscripten_atomic_wait_u32 doesnt' work on the main thread, so emscripten_futex_wait instead has to busy wait on the main thread.

So at the very least we need to have _emscripten_thread_supports_atomics_wait working in wasm workers so we can know if its safe to call emscripten_atomic_wait_u32 or not.

[sbc100]

OK, I jumped through some hoops to ensure that the cost of tracking the tread state is only payed for programs that use these APIs.

[sbc100]

@dschuff @kripken PTAL, this doesn't have the code size regression anymore so should no issue I hope.