Refactor and simplify component trampolines

[alexcrichton]

Note that this is based on #6691

In poking at #6696 I felt that the amount of boilerplate for defining
new kinds of trampolines in the component model was getting a bit
excessive. There was already 6 different types and I was adding two more
and I had to touch just a few too many places to get this done. In the
end I decided to refactor how trampolines are handled in the component
model to make it much easier to add new kinds of trampolines.

To that end the type-specific counts/lists/etc are all gone now in favor
of a single concept of a trampoline. This means components now track
trampolines in-bulk rather than individually by type. For example
compiling trampolines is now a loop over "compile this list of
trampolines" where previously it was N loops for the N types of
trampolines. The Trampoline definition is where the enum and dispatch
happens where that contains all possible trampolines that a component
could require.

This ended up being a large refactor to the Cranelift component
integration, but there is not intended to be any functional change from
this refactoring. Additionally all trampolines are now removed from the
global initializers list since there's nothing preventing them from
being initialized earlier on during the instantiation process.

Overall this should drastically reduce the number of locations that need
to have trampoline-specific knowledge to translation, the dataflow
graph, and compilation. Nearly everything else can operate over
everything in bulk and forward between these systems.

[github-actions]

Subscribe to Label Action

cc @fitzgen, @peterhuene

This issue or pull request has been labeled: "fuzzing", "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• fitzgen: fuzzing
• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[alexcrichton]

Ok this should be good to go now that #6691 has landed

[fitzgen]

Nice!

[alexcrichton]

cc @pchickey on that last failure, it may be a spurious failure?

test preview2::pipe::test::sink_write_stream ... FAILED

failures:

---- preview2::pipe::test::sink_write_stream stdout ----
thread 'preview2::pipe::test::sink_write_stream' panicked at 'assertion failed: `(left == right)`
  left: `1024`,
 right: `0`', crates/wasi/src/preview2/pipe.rs:671:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/core/src/panicking.rs:67:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
   4: wasmtime_wasi::preview2::pipe::test::sink_write_stream::{{closure}}
   5: tokio::runtime::context::runtime::enter_runtime
   6: wasmtime_wasi::preview2::pipe::test::sink_write_stream
   7: core::ops::function::FnOnce::call_once
   8: core::ops::function::FnOnce::call_once
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    preview2::pipe::test::sink_write_stream

test result: FAILED. 13 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.59s

error: test failed, to rerun pass `-p wasmtime-wasi --lib`