Continuation trapping semantics

[dhil]

This patch fixes a problem with traps on continuations, which would otherwise allow a Wasm program to continue running after invoking a trapping instruction. Currently, a fresh trap handler is installed per continuation stack, meaning that the effects of a trap is delimited by the stack segment on which the trap occurred -- whereas it really ought to be delimited by the top-level of the program (i.e. the part just before host/engine frames).

[alexcrichton]

I'm not familiar enough with the stack-switching code currently to review this myself. For example I don't know if this is accidentally skipping over native frames at the base of other continuations. Given that I'm going to defer to @fitzgen and @posborne as they're more familiar with the details

[dhil]

For example I don't know if this is accidentally skipping over native frames at the base of other continuations.

Excellent point. I think it may skip over intermediate invoke_wasm_and_catch_traps frames, suggesting that a "bubbling" semantics of trapping up through continuation stacks may be the right thing to do.