switcher cross-thread signaling can race the cross-call and -return paths

[nwf]

While writing #358, working towards #47, and thinking more about the switcher_interrupt_thread API, I realized it's possible to induce force unwinds rather than error handler invocation. The cross-call path can be preemptive (both before and after the call), and can be off core and "within" the same compartment as the caller of switcher_interrupt_thread.

Prior to the actual call at .Lswitch_callee_call, losing this race causes the call to be skipped, as coming back on core will see the injected error, then see that it is in the switcher, and, ultimately, jump ahead to switcher_after_compartment_call.

After the actual call, things are a little more exciting, even if the control flow proceeds similarly:

1. we might just clobber the return value of a completed call, if we're before the trusted stack frame update, because the instruction sequence is idempotent up to that point, or, more excitingly...
2. we might forcibly unwind out of the caller entirely, if we're after that point (just because we happened to be returning from a cross call at the time of being interrupted).

Probably we fix this at the same time as we fix #47 and maybe we do so in part by revising the interrupt mechanism (introduced, for reference, by #114). It almost certainly means that the cross-call and cross-return paths will involve short sequences of IRQ-deferred code, and it may be more convenient to use mret rather than cjalr to exit the TCB so that we can pick up atomic changes in IRQ disposition.