cranelift: Allow testing trap codes in CLIF run tests

👋 Hey,

#### Feature

This was brought up by @dheaton-arm on [zulip](https://bytecodealliance.zulipchat.com/#narrow/stream/217117-cranelift/topic/testing.20traps/near/294881598). We should add a trap comparison operator to our CLIF test suite.

#### Benefit

As @cfallin [mentions in the thread](https://bytecodealliance.zulipchat.com/#narrow/stream/217117-cranelift/topic/testing.20traps/near/294893024) we already have reasonable coverage for traps via the wasm test suite.

However, this is still useful to improve the CLIF interpreter, to ensure that we are consistent in emitting the appropriate traps at the right time.

This could further be used in the clif differential fuzzer. The fuzzer currently stops executing any input, as soon as the interpreter traps.
This is overly restrictive since we could allow a `DivByZero` to execute in the backend and ensure that it comes up with the same trap. Other traps are also useful to check, but not all! We don't want to let a stack overflow keep executing since that can overwrite some memory and do terrible things.

I think this is also important if we want to start using the interpreter for const code execution, since we do need to ensure that we produce the same traps, and enabling it in the fuzzer is the best way I can think about it currently.

#### Implementation

We can add a trap handler either directly in `cranelift-jit` or the trampolines in the runtest suite. I'm not too familiar with how traps work in general to be able to expand on this.

#### Alternatives

So far I've been writing tests that trap in the interpreter test suite, and that is a viable option. But its not very scalable.

A very out of the box option would be to run wasmtime with the clif interpreter and use the wasm test suite and fuzzers to do this! I would love to do this, but right now its a bit too out there.