Support executing Pulley in Wasmtime

[alexcrichton]

This commit is the initial implementation of executing the Pulley
interpreter from the wasmtime crate. This gives access to all of the
wasmtime crate's runtime APIs backed by execution of bytecode in
Pulley. This builds on the previous PRs I've been making for support in
Pulley to culminate in testing on CI in this PR. This PR handles some
final tidbits related to producing a runnable image that can be
interpreted by the wasmtime crate such as:

• Pulley compilation artifacts are no longer marked as natively
  executable, just read-only.
• Pulley compilation artifacts include wasm-to-array trampolines like
  normal platforms (removes a pulley special-case).
• Dispatch of host calls from Pulley to the Wasmtime runtime are
  implemented.
• Pulley's list of panicking wasm features is slimmed down as most are
  covered by "this lowering isn't supported" errors.
• Execution of wasm code now has an if to see whether Pulley is
  enabled within a Store or not.
• Traps and basic "unwinding" of the pulley stack are implemented (e.g.
  a "pulley version" of setjmp and longjmp, sort of)
• Halting the interpreter has been refactored to help shrink the size of
  ControlFlow<Done> and handle metadata with each done state.

Some minor refactorings are also included here and there along with a
few fixes here and there necessary to get tests passing.

The next major part of this commit is updates to our wast test suite
and executing all *.wast files. Pulley is now executed by default for
all files as a new execution engine. This means that all platforms in CI
will start executing Pulley tests. At this time almost all tests are
flagged as "expected to fail" but there are a small handful of
allow-listed tests which are expected to pass. This exact list will
change over time as CLIF lowerings are implemented and the interpreter
is extended.

Follow-up PRs will extend the testing strategy further such as:

• Extending #[wasmtime_test] to include Pulley in addition to Winch.
• Getting testing set up on CI for 32-bit platforms.

[alexcrichton]

I'll note that this is in draft form as it currently is based on #9743. I'm going ahead and opening this up to see what CI has to say about this.

[github-actions]

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• If you added a new Config method, you wrote extensive documentation for
  it.

  Our documentation should be of the following form:

  Short, simple summary sentence.
  
  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.
  
  Is this method fallible? If so, when can it return an error?
  
  Can this method panic? If so, when does it panic?
  
  # Example
  
  Optional example here.
  

• If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in wasmtime_fuzzing::Config (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See our docs on fuzzing for more details.

• If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

---

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

[alexcrichton]

@fitzgen ok should be rebased and updated, I believe s390x CI is failing but I think most of the rest should be passing. Once results come in I'll figure out how to best ignore s390x for now.

[fitzgen]

Very nice! Super excited to see this progress!

A few nitpicks and suggestions below, but nothing major

[fitzgen]

Curious: why was this change needed?

[alexcrichton]

Ah this is due to some other rule only accepting 32 or 64-bit inputs which causes ISLE to panic as something not a partial constructor. Basically tests panic unless this is here, so a future refactoring will need to flesh out more lowering rules for 8/16-bit types.