asyncFlow should directly support E via promise handlers

[erights]

See #9097 (comment)

makeGuestForHostVow will need to create a handled promise whose handler reflects an invocation into a logged checkSend, which is analogous to checkCall. But where checkCall proceeds to do a synchronous host call, checkSend needs to do a host eventual-send. An important design question is what the hander should do with the host promise for the result of the host eventual send, since it can only track host vows, not host promises.

Likewise, makeGuestForHostRemotable will need to use the handled promise API to create the guest remotable as a remote presence. Unlike liveslot remote presences, this one can retain the same one methods that the current makeGuestForHostRemotable gives it, if the host remotable is just a local far object with methods. These will still support synchronous guest-side calls. But a guest use of E to do an eventual send will bypass these guest-side methods and go directly to the appropriate promise handler which acts like the one described above.

So the extra log opcode this will need is checkSend. The "return" side should already be well taken case of by doFulfill and doReject. Huh. The doFulfill and doReject don't happen until the host promise is settled, so we'd only need to convert a settled host promise to a settled host vow for the log, which is not a problem. Whew! (@mhofman , you might have tried to explain it to me and I didn't get it until now.)

[erights]

Although this support will likely happen after #9097, it needs to happen before we commit to durable log state on chain, since this E support will take some correct programs that work, leaving behind one log, into one that behaves the essentially the same but produces a different log, causing it to fail replay.

[erights]

If #9301 has already happened without checkSend or doSend, then to fix this issue in that context, we'll also need to add the dual opcode doSend.

[erights]

Capturing here what @mhofman wrote at #9097 (comment)

When supporting E, the handler is given a resultP for send operations. That resultP is the guest promise, and the result promise returned by the send handler is adopted by that promise, so the resolvers of the returned promise can be mapped to the resultP guest promise. The bijection can map the resultP guest promise to the host vow / result promise of the actual eventual send performed on the host object.