Terminate workers blocked in Atomics.wait() when recording

[Andarist]

A worker blocked in Atomics.wait() and terminated while recording never stopped, so the process never exited. The stop watchdog (#173) invalidated the recording after 5s and terminated the worker's execution, which woke the futex wait. But FutexEmulation::WaitSync handles interrupts with events disallowed (#170), and StackGuard::HandleInterrupts ignores interrupts while events are disallowed (#173, ported from replayio/chromium-v8#30). The termination stayed pending and the waiter went back to waiting on the futex emulation's condition variable, with the parent idle in its event loop, waiting for the worker's exit.

WaitSync now handles a termination that HandleInterrupts left pending. Only another thread can terminate a thread blocked there, which already invalidates the recording (StackGuard::RequestInterrupt), so this doesn't change what a usable recording or its replay does. Other interrupts are still left for the next stack check, and without recording HandleInterrupts has already handled the termination, so the check is a no-op.

Once the recording is finished, Worker::Exit now stops workers right away instead of posting the stop to their event loop and starting the stop watchdog. When the parent exits, through process.exit() or the end of its event loop, the recording is already finished before stop_sub_worker_contexts runs, so a deterministic stop gains nothing: a worker that never returned to its event loop, e.g. one blocked in Atomics.wait(), held up the exit for the watchdog's 5s. With a stuck worker, exiting now takes about as long as on stock node 16.

Tested with https://github.com/replayio/backend/pull/13450 and its test/node-recording/tests/worker-threads/terminate-stuck/