This commit is the first half and the meat of the implementation
of bytecodealliance#1774 where, by default, WIT processing tools will now merge world
imports when possible based on semver versions. The precise shape of how
this is done has gone through a few iterations and this is the end
result I've ended up settling on. This should handle all the various
cases we're interested in and continue to produce valid worlds within a
`Resolve` (with the help of `elaborate_world` added in bytecodealliance#1800). CLI
tooling has been updated with flags to configure this behavior but the
behavior is now enabled by default.

This commit is a lead-up to the changes proposed in bytecodealliance#1774. The
`wit-component` crate is quite old and has gone through many iterations
of the component model and it's very much showing its age in a few
places. Namely the correlation between component model names and core
wasm names is open-coded in many places throughout validation and
encoding of a component. This makes the changes in bytecodealliance#1774 where the names
may be different (e.g. core wasm 0.2.0 might import component 0.2.1).

Making this change was inevitably going to require quite a lot of
refactoring of `wit-component`, so that's what this commit does. It's a
pretty large rewrite of the internals of validation of a core wasm
module and adapter prior to creating a component. The metadata produced
by this pass is now represented in a completely different format. The
metadata is extensively used throughout the encoding process so encoding
has been heavily refactored as well.

The overall idea is that the previous "grab bag" of various items here
and there produced from validation are now all unified into a single
`ImportMap` and `ExportMap` for a module. These maps track all the
various kinds of imports and exports and how they map back to core wasm
names. Notably this means that the logic to correlate core wasm names
with component model names is now happening in just one location (in
theory) as opposed to implicitly all throughout encoding. I've
additionally taken this opportunity to subjectively simplify much of the
encoding process around managing instantiations of core wasm modules and
adapters.

One of the main changes in this commit is that it does away with code
structure such as "do the thing for WIT" then "do the thing for
resources" then "do the thing for other resources" and finally "do the
thing for adapters". This was difficult to understand every time I came
back to it and I can't imagine was easy for anyone else to understand
either. All imports are now handled in a single location and it's
intended to be much better separated who's responsible for what. For
example the code satisfying an import is decoupled from what the import
is going to be named and how it's provided to the main core wasm module.

Overall the intention is that this does not either enhance the
functionality of wit-component nor regress it. Lots of tests have
changed but I've tried to verify it's just things moving around as
opposed to anything that has a different semantic meaning. A future PR
for bytecodealliance#1774 will enhance the logic of connecting core wasm imports to WIT
imports but that's deferred for a future PR.

This commit is a lead-up to the changes proposed in bytecodealliance#1774. The
`wit-component` crate is quite old and has gone through many iterations
of the component model and it's very much showing its age in a few
places. Namely the correlation between component model names and core
wasm names is open-coded in many places throughout validation and
encoding of a component. This makes the changes in bytecodealliance#1774 where the names
may be different (e.g. core wasm 0.2.0 might import component 0.2.1).

Making this change was inevitably going to require quite a lot of
refactoring of `wit-component`, so that's what this commit does. It's a
pretty large rewrite of the internals of validation of a core wasm
module and adapter prior to creating a component. The metadata produced
by this pass is now represented in a completely different format. The
metadata is extensively used throughout the encoding process so encoding
has been heavily refactored as well.

The overall idea is that the previous "grab bag" of various items here
and there produced from validation are now all unified into a single
`ImportMap` and `ExportMap` for a module. These maps track all the
various kinds of imports and exports and how they map back to core wasm
names. Notably this means that the logic to correlate core wasm names
with component model names is now happening in just one location (in
theory) as opposed to implicitly all throughout encoding. I've
additionally taken this opportunity to subjectively simplify much of the
encoding process around managing instantiations of core wasm modules and
adapters.

One of the main changes in this commit is that it does away with code
structure such as "do the thing for WIT" then "do the thing for
resources" then "do the thing for other resources" and finally "do the
thing for adapters". This was difficult to understand every time I came
back to it and I can't imagine was easy for anyone else to understand
either. All imports are now handled in a single location and it's
intended to be much better separated who's responsible for what. For
example the code satisfying an import is decoupled from what the import
is going to be named and how it's provided to the main core wasm module.

Overall the intention is that this does not either enhance the
functionality of wit-component nor regress it. Lots of tests have
changed but I've tried to verify it's just things moving around as
opposed to anything that has a different semantic meaning. A future PR
for bytecodealliance#1774 will enhance the logic of connecting core wasm imports to WIT
imports but that's deferred for a future PR.

This commit is the first half and the meat of the implementation
of bytecodealliance#1774 where, by default, WIT processing tools will now merge world
imports when possible based on semver versions. The precise shape of how
this is done has gone through a few iterations and this is the end
result I've ended up settling on. This should handle all the various
cases we're interested in and continue to produce valid worlds within a
`Resolve` (with the help of `elaborate_world` added in bytecodealliance#1800). CLI
tooling has been updated with flags to configure this behavior but the
behavior is now enabled by default.

* Overhaul and refactor some internals of `wit-component`

This commit is a lead-up to the changes proposed in #1774. The
`wit-component` crate is quite old and has gone through many iterations
of the component model and it's very much showing its age in a few
places. Namely the correlation between component model names and core
wasm names is open-coded in many places throughout validation and
encoding of a component. This makes the changes in #1774 where the names
may be different (e.g. core wasm 0.2.0 might import component 0.2.1).

Making this change was inevitably going to require quite a lot of
refactoring of `wit-component`, so that's what this commit does. It's a
pretty large rewrite of the internals of validation of a core wasm
module and adapter prior to creating a component. The metadata produced
by this pass is now represented in a completely different format. The
metadata is extensively used throughout the encoding process so encoding
has been heavily refactored as well.

The overall idea is that the previous "grab bag" of various items here
and there produced from validation are now all unified into a single
`ImportMap` and `ExportMap` for a module. These maps track all the
various kinds of imports and exports and how they map back to core wasm
names. Notably this means that the logic to correlate core wasm names
with component model names is now happening in just one location (in
theory) as opposed to implicitly all throughout encoding. I've
additionally taken this opportunity to subjectively simplify much of the
encoding process around managing instantiations of core wasm modules and
adapters.

One of the main changes in this commit is that it does away with code
structure such as "do the thing for WIT" then "do the thing for
resources" then "do the thing for other resources" and finally "do the
thing for adapters". This was difficult to understand every time I came
back to it and I can't imagine was easy for anyone else to understand
either. All imports are now handled in a single location and it's
intended to be much better separated who's responsible for what. For
example the code satisfying an import is decoupled from what the import
is going to be named and how it's provided to the main core wasm module.

Overall the intention is that this does not either enhance the
functionality of wit-component nor regress it. Lots of tests have
changed but I've tried to verify it's just things moving around as
opposed to anything that has a different semantic meaning. A future PR
for #1774 will enhance the logic of connecting core wasm imports to WIT
imports but that's deferred for a future PR.

* Update link-related tests

* Bless some more tests

This commit is the first half and the meat of the implementation
of bytecodealliance#1774 where, by default, WIT processing tools will now merge world
imports when possible based on semver versions. The precise shape of how
this is done has gone through a few iterations and this is the end
result I've ended up settling on. This should handle all the various
cases we're interested in and continue to produce valid worlds within a
`Resolve` (with the help of `elaborate_world` added in bytecodealliance#1800). CLI
tooling has been updated with flags to configure this behavior but the
behavior is now enabled by default.

This commit implements the final bit of bytecodealliance#1774 where the `wit-component`
crate will now match imports based on semver version in addition to the
previous exact-name matching that was performed previously.

* Implement merging semver-compatible interfaces in imports

This commit is the first half and the meat of the implementation
of #1774 where, by default, WIT processing tools will now merge world
imports when possible based on semver versions. The precise shape of how
this is done has gone through a few iterations and this is the end
result I've ended up settling on. This should handle all the various
cases we're interested in and continue to produce valid worlds within a
`Resolve` (with the help of `elaborate_world` added in #1800). CLI
tooling has been updated with flags to configure this behavior but the
behavior is now enabled by default.

* Add broken test case for wit-component

* Match wasm/component import names based on versions

This commit implements the final bit of #1774 where the `wit-component`
crate will now match imports based on semver version in addition to the
previous exact-name matching that was performed previously.

* Don't panic on duplicate shims in wit-component

This is now possible with import version matching so refactor the
internal data structures to better support insertion of possibly
duplicate shims. Most of wit-component was already ready for this
refactoring, it was just the initial generation of shims that needed to
be reorganized slightly.

* wip

* Elaborate all worlds after semver merging

Any interface could be modified, so elaborate all of them to fixup anything
that needs new imports.

* Only merge once at the end, not continuously

This commit updates how the semver-merging bits of `Resolve` work by
moving it towards the end of the encoding process rather than
once-per-world-merged. That helps both deduplicate work and fix some
asserts I'm seeing that are tripping if a `Resolve` is import-merged and
then merged again elsewhere.

This additionally simplifies some APIs because the boolean of what to do
isn't threaded to quite so many locations.

* Fix test

* Update interface deps of exports too

Dependencies might depend on replaced interfaces so the dependency edges
there need to be updated in the same manner as imports.

* Fix fuzzer build

Also ensure to at least try to test the new merging function.