Prior to this, `abort()` was just one one way of fulfilling the abort promise, but other ways were joined into the promise in the constructor. Confusingly, this meant that `abortException` was not set correctly when aborting for any of those other reasons.

Now the constructor calls `abortWhen()` to wait on each of those promises that were previously joined in. When any promise passed to `abortWhen()` eventually rejects, `abort()` is called.

I can't think of any reason why this was done in a different place, so let's consolidate.

… as well.

I couldn't find any existing test.

I've always wanted to do this. Node's process.exit() already figured it out, so this copies its technique.

Relatedly, we can have `runImpl()` rethrow the correct abort exception, yay.

This means they don't need the `finalize()` mechanism anymore.

Also this means we don't need to separately join with `onAbort()` in `WorkerEntrypoint::request()`, becaues the thing `ServiceWorkerGlobalScope::request()` returns is already an `awaitJs()` promise.

Note: This has nothing to do with GC finalization.

This was sort of an alternative abort mechanism where we could cause all promises exported from the IoContext to reject when we detected a hang via PendingEvents. We can just use `abort()` instead.

It doesn't really make sense that we'd null it out specifically after a hang but not in other cases.

Also remove the seemingly-irrelevant nulling out of `promiseContextTag` after a hang.

This should prevent lingering tasks from failing later due to there being no IncomingRequest. I'm pretty sure the only way that happens is when the actor was aborted.

There are now two methods:

* js.terminateNextExecution(), which has the previous behavior.
* js.terminateExecutionNow(), which forces the termination to happen synchronously and always throws.

This lets us take the hack that had proliferated to three different places and keep it in one place.