Migrate Wizer to `wasmtime::error` (#12266)

wizer: Partially support nested components (#11898)

* wizer: Partially support nested components

Support nested components insofar as they don't have access to modules
at this time. This helps `was

wizer: Partially support nested components (#11898)

* wizer: Partially support nested components

Support nested components insofar as they don't have access to modules
at this time. This helps `wasmtime wizer` support wasm-tools-generated
components which use nested components for type-ascribing exports.
Otherwise though nested components are not allowed to defined or
instantiate core modules as that would need more implementation in Wizer
to support.

* Two-level test too

* Add test.wasm to wizer's gitignore

* Fix test

show more ...

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 ...