This should fix these errors:

    [wasm test] [23:10:04] dbug: Reached wasm exit
    [wasm test] [23:10:04] info: node:internal/process/promises:246
    [wasm test] [23:10:04] info:           triggerUncaughtException(err, true /* fromPromise */);
    [wasm test] [23:10:04] info:           ^
    [wasm test] [23:10:04] info:
    [wasm test] [23:10:04] info: [UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "#<ExitStatus>".] {
    [wasm test] [23:10:04] info:   code: 'ERR_UNHANDLED_REJECTION'
    [wasm test] [23:10:04] info: }
    [wasm test] [23:10:04] info:
    [wasm test] [23:10:04] info: Node.js v17.3.1
    [wasm test] [23:10:04] info: Process node.exe exited with 1

…Pool.WorkerThread

This is a LIFO semaphore with an asynchronous wait that triggers
callbacks on the JS event loop in case of Release or timeout.

no changes yet. just copying verbatim to a separate file

make sure to keep the thread alive after setting up the semaphore
wait.
Cleanup the thread when exiting

Match the C logging for easier grepping

Don't explicitly call UnwindToJs as it doesn't know about managed
code.
Also avoid mono_thread_exit as that also won't necessarily clean up
after the interpreter

Add a flag to mono's thread start wrappers to keep track of threads
that may not want cleanup to run after the Start function returns.

Use the flag when starting threadpool threads.

…o-op

Keep a thread local counter in mono. that we "know" will be right for
us and manually call unwind_to_js and thread_exit.

This is super-fragile since we don't know what emscripten internals
might be trying to manipulate the keepalive count and also we are
exiting the thread with active managed frames, so we might be skipping
finally clauses and possibly leaking interpreter memory.

This is mainly meant to keep work going on this branch and not
something we necessarily want to commit

fixes smoketest on Release builds

Share the code between non-browser implementations and
browser+threads.

The differences are just in how the work loop is started and implemented

don't need both user data and a gchandle

prefix functions with mono_lifo_semaphore_asyncwait_

…s.Mono.cs

…t semaphore

Set WorkerThread.IsIOPending when the current thread has unsettled JS
interop promises.

When IsIOPending is true, the worker will not exit even if it has no
more work to do.  Instead it will repeatedly wait for more work to
arrive or for all promises to settle.

the delay is longer that the threadpool worker's semaphore timeout, in
order to validate that the worker stays alive while there are
unsettled promises