WASMFS JS proxy thread assertion too strict

Right now, JS code in Module.onRuntimeInitialized can’t create certain WASMFS backends before main runs, which is something that’s possible in the JS filesystem and possible under wasmfs with JSPI. This is because e.g. fetchfs and opfs backends (as well as thread_util.h’s ProxyWorker) currently assert at construction time that they are either not on the main thread or they are running with JSPI.

The motivation behind these assertions is that the main thread may not be able to spawn a thread in a fresh worker without causing a deadlock, but sometimes it’s possible to do this safely (either to succeed or at least to fail if a worker is not available). Specifically, if the worker pool has a free unused worker, spawning a thread will definitely succeed.

While there is currently no api the C code could use to detect whether a worker is free, when run under PTHREAD_POOL_STRICT > 0 the worker fetching code will throw a warning (if strict = 1) or error out (if strict = 2) in the condition where a deadlock could happen by spawning a new worker from the main thread. I therefore think the assertions should be conditionally compiled in only when PTHREAD_POOL_STRICT is 0, and the overly strict condition now amounts to a bug.