Refactor the internals of handling traps/unwinds

[alexcrichton]

This commit at a high level primarily addresses the test case added here. Specifically if a debug handler, on an exception event, takes the exception from the store then previously that would cause Wasmtime to abort the process. This bug is now fixed, and the fix is done by performing a refactor of the surrounding code that panicked.

The main change implemented here is to deduce what to do in the face of a wasm trap after a debug handler is invoked, not before. This is because a debug handler could remove the exception or even change the exception being thrown throughout its invocation. This means that we don't actually know what's going to happen until after the debug handler is invoked.

Upon moving this code around, however, I noticed that a lot of historical structure in traphandlers.rs was at this point no longer necessary. Much of this commit is then trimming down the abstractions in this file and reorganization how exactly everything is handled. For example the Box<Trap> to hand over to crate::trap is created much sooner in the "slow" path where a trap happens rather than the "hot function" where wasm is being invoked. Additionally the number of variants and storage in various enums were all trimmed down to basics to represent the smaller set of states that are now possible.

Finally, this change additionally updates the debugger WIT world that Wasmtime exports by removing the difference between caught-exception-thrown and uncaught-exception-thrown. Now instead there's just exception indicating that an exception is being thrown. Whether it's going to be caught depends on whether the debugger changes the exception or not. In the future if the distinction is necessary I figure we can add some more methods for inspecting the state.

Closes #13308

[alexcrichton]

This change turns out to additionally fix a heap corruption issue as well. Previously it was possible to change the exception being thrown in a debug handler, but the wasm catch wasn't updated, so it was possible to jump to a handler expecting one exception type when it actually caught another.