This will enable easier reuse soon.

If, after the initial JS RPC call is complete, some capabilities have been exchanged between the client and server and are still held, we want the session to remain open until those go away. That means that `GetJsRpcTargetCustomEventImpl::run()` should not complete in the meantime.

To accomplish this, we use some capnp membranes.

I decided the old name was confusing given that the method does not return until the session is done. The new name also makes the name of the CustomEvent implementation a lot nicer, as is a better operation name for Jaeger tracing purposes.

Note that the rename does not affect the Cap'n Proto communications on the wire, since the ordinal numbers remain the same.

The `RevokerMembrane` in `JsRpcSessionCustomEventImpl::sendRpc()` will already take care of propagating errors.

The `WorkerRpc` type can now be used to represent capabilities received across RPC. It couldn't do that while also extending `Fetcher`.

`Fetcher` itself now has its own wildcard property that invokes its own version of `getRpcMethod()`. `Fetcher`'s version starts a new session, whereas `WorkerRpc::getRpcMethod()` now operates within an existing session.

An alternative design would have been to keep `WorkerRpc` as it is, and introduce a new separate class to represent non-top-level capabilities. This is something we debated before. I felt that it made more sense to push this down into `Fetcher` because:
- The existence of `WorkerRpc` was already preventing `Fetcher` from adding new methods, since they would override any RPC method with the same name. So having RPC pulled into a separate subclass didn't really avoid affecting `Fetcher`. I like putting these issues all in one place.
- I think it will be cumbersome to mark bindings on the client side as supporting RPC or not, so that we can decide whether to make them a `WorkerRpc` vs. `Fetcher`. I'd rather they just all have the same type and the endpoint throws an error from `jsRpcSession` if it doesn't do RPC.

Note that I think we should rename `Fetcher` to something that makes clear it does more than just fetch. I don't have a great idea for a name yet, though.

This better-reflects its new meaning.