User-facing proxying APIs should not use the system queue

Emscripten supports many different proxying APIs such as

- `MAIN_THREAD_EM_ASM` and friends
- `emscripten_sync_run_in_main_thread`, `emscripten_dispatch_to_thread`, and friends from emscripten/threading.h
- The new `proxying.h` APIs

Since proxying.h is so new, most existing code would use the former two APIs. In particular, I expect that `MAIN_THREAD_EM_ASM` is extremely common because it is so simple to use.

The problem is that the non-proxying.h APIs use the system proxying queue to do their proxying. The system proxying queue is pumped at every pthread cancellation point, so the proxied code may run at nearly arbitrary points, including times at which the main thread is in some intermediate state that is not meant to be observed by external code. Work proxied on the system proxying queue essentially needs to be treated like a signal handler to be entirely safe.

We should update `MAIN_THREAD_EM_ASM` and the other user-facing proxying APIs to use a separate queue that is not pumped at pthread cancellation points so that more work can be proxied safely. System-level work that does need to be executed at cancellation points should shift to use new internal proxying functions that continue to use the system queue.