This avoids the need to check the `weakIoContext` in `JsRpcTargetBase::call()` before calling the callback, which is nice because the callback already holds its own weak ref and does its own check.

This can be completely handled by the re-entry callback now.

Since we're no longer using the hack where `callImpl()` runs as part of a `ctx.addTask()`, it's now the case that the promise returned by `callImpl` will be canceled if the incoming RPC is canceled. The whole reason to hold onto `thisCap` is because if the RPC was canceled, then the RPC server could subsequently be dropped, but the addTask()ed callImpl() could still be running, so it needed to make sure `this` didn't disappear under it. But now the body of `callImpl()` will actually be canceled, so it doesn't matter if `this` goes away.

We still do need `ownCallContext`, but we can acquire it later than we did before, inside the body of `callImpl()` -- because if the call is canceled before that, we won't get to this point anyway.

`makeReentryCallback()`, as its name implies, is for *re-*entry, not original entry.

In particular, the callback itself holds a PendingEvent. This does not make sense at the top level, as it would mean there is always a PendingEvent, breaking the whole mechanism for RPC events. (I've added a test which was broken by this.)

It turns out, for the top-level call, we don't really need the complexity of `makeReentryCallback()` anyway. We can arrange to ensure that EntrypointJsRpcTarget cannot outlive the IoContext / IncomingRequest, then just use ctx.run() like normal.

Since the re-entry callback already holds one.

This forces a test failure in an internal test that triggers this behavior -- or at least it did, before the changes in this PR fixed the problem (since we no longer use addTask() for individual RPCs).

That said, the deeper bug isn't really fixed, which is that abort handling is extremely messy and does not actually cancel all outstanding tasks. That will require more work.