Proxying of stdio output to main thread

Currently, when using pthreads, stdio output is by default proxied back to the `Module` instantiation thread. This isn't necessary since by default it just uses console.log, which works on workers as well as the browser main thread.

One complication is that IIUC currently the proxying happens all in one place for all the syscalls, and when the user overrides [`Module.print`](https://emscripten.org/docs/api_reference/module.html#Module.print), that callback currently also is called on the main thread. So changing how the write syscalls are proxied could break code that overrides `Module.print`. (Anecdotally it seems that this is somewhat common, and I think the default emscripten HTML shell does it in order to put the output into the virtual console, which would have to be on the main thread).

More generally it would be good to have better documentation (and possibly even control?) about which Module APIs and/or C APIs and/or syscalls could cause proxying (since especially if the aplication main thread is itself a worker, then it could deadlock if that thread never returns to the event loop or calls a pthread API), and about which thread callbacks are called on.