Merge component-init into wasmtime-wizer (#11878)

* Merge component-init into wasmtime-wizer

This commit is the next phase of merging the wizer and component-init
repositories into Wasmtime. This d

Merge component-init into wasmtime-wizer (#11878)

* Merge component-init into wasmtime-wizer

This commit is the next phase of merging the wizer and component-init
repositories into Wasmtime. This does not take the same approach as
merging wizer where the git histories were merged, but instead this
takes an entirely different approach for component-init. Effectively I
read the code in component-init and copied over the spirit of the code
into the wasmtime-wizer crate. Very little was literally copied over due
to such large changes in the internals of organization and
implementation. The main goal of merging this repository is to replace
the core wasm tracking of state in component-init with what
wasmtime-wizer already has. Sort of like the runtime in the `wasmtime`
crate the goal is to build component support entirely on top of core
support to avoid duplicating anything.

The general strategy for pre-init components is that unlike core wasm
where more exports are added a component has a new module and new
accessor functions injected for all state found in the component. For
example an `i32` global results in a `(func (result s32))` in WIT.
Memories result in `(func (result (list u8)))`. This "accessor module"
is synthetically built during the instrumentation pass of Wizer and then
used to acquire snapshot results afterwards.

All of this support is added in a new `component` submodule of the
`wasmtime-wizer` crate. This submodule has the same structure as its
core wasm counterpart at the root of the crate, but the internal
implementations are entirely different. Anything encountering a core
wasm module delegates to the core wasm support in the root of the crate
for Wizer.

There is one new limitation at this time over what component-init
supports which is that nested components are not supported just yet.
Currently in component-init nested components are copied over as-is
which ends up producing a faulty initialization if the components
actually have core wasm instances associated with them. For now this
implementation sidesteps this by forbidding nested components entirely.
To support wizening the output of `wasm-tools component {new,link}`,
however, some support for nested components will be required. I plan on
adding that in a follow-up commit.

Testing of component-init is pretty light right now so this commit
copies over a few `*.wat` tests "in spirit" but does not literally copy
over the preexisting tests. There are a few tests in component-init
which initialize the real output of `wasm-tools component new` which may
want to be migrated eventually but my hope is that this repo can stick
to smaller more focused tests for now.

One large-ish change made to `wasmtime-wizer` during this merge was to
change snapshotting functionality to being an `async` function. This is
required for components because reading state requires invoking a
function, which in the context of the `wasmtime run` subcommand is
always done in "async mode". This meant that the `async` propagates
outwards to much of `wasmtime-wizer`, even the core wasm traits. My hope
is that this isn't a big issue as the CLI can deal with it and embedders
can throw an `async` in there.

Overall this is intended to be a mostly-complete skeleton plus basic
functionality for component-init. I have not done thorough testing with
real-world components just yet (e.g. componentize-py) so there will
likely be follow-up PRs to address various inevitable shortcomings I've
introduced in this merge.

* Deduplicate some debug asserts

* Fix wizer benches/fuzzing

* Use `wizer-initialize` for core wasm and components

* Only copy out nonzero contents of memory, not all memory

* Fix a rebase conflict

* Revert "Only copy out nonzero contents of memory, not all memory"

This reverts commit 865146cc459826945cd22f4a41f1137d3e8c1c46.

show more ...

Integrate wizer into this repository (#11805)

* Remove misc wizer-related files

* Integrate the Wizer manifest with this repo's workspace

* Enable some more wasmtime features

* Get wizer tests pa

Integrate wizer into this repository (#11805)

* Remove misc wizer-related files

* Integrate the Wizer manifest with this repo's workspace

* Enable some more wasmtime features

* Get wizer tests passing in-repo

* Remove duplicate dummy wizer module

* Integer `wasmtime wizer` subcommand into the CLI

* Fully integrate wizer into `wasmtime` CLI

* Split `wasmtime run` into helper functions
* Split `Wizer::run` into helper functions
* Weave the two together in `wasmtime wizer`

The end goal is to have all CLI options in `wasmtime run` applicable for
`wasmtime wizer` as well with some light edits between the two. Overall
though we shouldn't have to proactively support commands in one or the
other and everything ideally should "just work".

* Fix clippy warnings and bench compiles

* Fix benchmarks

* Create a store-per-iteration
* Use the right wasms in the regex benchmark

* Get wizer fuzzer building again

* Get CLI working again

* Run rustfmt

* Remove precompiled wasms from the tree

35M for some wasms is a bit heavy so instead build them from source.

* Update vet configuration for fuzzers/tests

* Update publish script with wasmtime-wizer

* Fix clippy lint

* Some docs and more clippy lints

prtest:full

* Relax version requirement

* Try to fix asan build

* Remove rustflags too

* Un-exclude wizer

* Adjust publish script

* Update lock file after rebase

* Integrate bytecodealliance/wizer#139

Use deterministic results for relaxed simd operations by default.

* Handle preloads in wizer

* Appease clippy

* Use deterministic relaxed simd in wizer tests

show more ...