…d `externref` (bytecodealliance#9435)

* Implement the Wasm GC instructions for converting between `anyref` and `externref`

This commit implements two instructions:

1. `any.convert_extern`
2. `extern.convert_any`

These instructions are used to convert between `anyref` and `externref`
values. The `any.convert_extern` instruction takes an `anyref` value and
converts it to an `externref` value. The `extern.convert_any` instruction takes
an `externref` value and converts it to an `anyref` value.

Rather than implementing wrapper objects -- for example an `struct
AnyOfExtern(ExternRef)` type that is a subtype of `AnyRef` -- we instead reuse
the same representation converted references as their unconverted reference. For
example, `(any.convert_extern my_externref)` is identical to the original
`my_externref` value. This means that we don't actually emit any clif
instructions to implement these Wasm instructions; they are no-ops!

Wasm code remains none-the-wiser because it cannot directly test for the
difference between, for example, a `my_anyref` and the result of
`(extern.convert_any my_anyref)` because they are in two different type
hierarchies, so any direct `ref.test` would be invalid. The Wasm code would have
to convert one into the other's type hierarchy, at which point it doesn't know
whether wrapping/unwrapping took place.

We did need some changes at the host API and host API implementation levels,
however:

* We needed to relax the requirement that a `wasmtime::AnyRef` only wraps a
  `VMGcRef` that points to an object that is a subtype of `anyref` and similar for
  `wasmtime::ExternRef`.

* We needed to make the `wasmtime::ExternRef::data[_mut]` methods return an
  option of their associated host data, since any `externref` resulting from
  `(extern.convert_any ...)` does not have any associated host data. (This change
  would have been required either way, even if we used wrapper objects.)

* fix tests

* fix wasmtime-environ tests

…odealliance#9436)

…nce#9438)

Just gluing our existing `ref.test` and conditional branching support together.

…9433)

This commit codifies the process [documented
here](https://github.com/bytecodealliance/rfcs/blob/main/accepted/vulnerability-response-runbook.md)
in the Wasmtime repository as it relates to Wasmtime itself. There's
also a few minor changes from recent advisories such as:

* We'll no longer use the publish-the-changes-from-the-advisory feature
  from GitHub. That basically just doesn't work any more.
* PRs will instead be manually created to have CI run on them to weed
  out any issues.
* Details about preparing the `main` branch ahead of the release are
  interleaved with the rest of the runbook.

The intention is to supplement the official runbook with
Wasmtime-specific information and flesh out a few minor steps we're
following that are "extra" here too.

…t linking and subtyping (bytecodealliance#9446)

* Enable some miscellaneous GC spec tests

These weren't caught by our checks that `should_fail` tests do not pass, I think
because they only contain modules that should validate, and not any actual
assertions.

* Require declared subtyping when linking module import/export functions

We were previously incorrectly doing a (shallow) match on structure when we
should have been doing a subtyping check.

…9256) (bytecodealliance#9447)

* Update `decommit_batch_size` type to `usize`

* Add missing pooling options to `OptimizeOptions`

* Add new pooling options to configuration

* Add `max_memory_protection_keys` option

also rename `memory_protection_keys` to `pooling_memory_protection_keys`

* Add `total_gc_heaps` option

* Add default options in comments

Help trim version of wasm-tools crates.

* Update docs/stabilization of wasm proposals

This commit updates our documentation and documented status of various
WebAssembly proposals. The goal of this commit it to explicitly list all
requirements for each WebAssembly proposal in a way such that enabling a
feature requires actively checking this table and performing effort to
fill in. This is intended to mitigate GHSA-q8hx-mm92-4wvg where it was
found that we were accidentally not fuzzing tail calls but had enabled
it by default.

This shuffles around some documentation, modernizes a bit, and notably
tries to list out a green checkbox or red X for the status of various
proposals. Notes for "holes" in the "on by default matrix" are also
added.

* Add a link to the GC tracking issue

* Tweak the list of supported targets

Android is listed in Tier 3 now

…ytecodealliance#9448)

* Implement subtype checking for `[return_]call_indirect` instructions

When Wasm GC is enabled, the `[return_]call_indirect` instructions must do full
subtyping checks, rather than simple strict equality type checks.

This adds an additional branch and slow path to indirect calls, so we only emit
code for this check when Wasm GC is enabled, even though it would otherwise be
correct to always emit it (because the `is_subtype` check would always fail for
non-equal types, since there is no subtyping before Wasm GC).

* fix no-gc builds

…9451)

…iance#9453)

This helps us keep track of their code quality, and the way that some of them
are reusing our implementation of `ref.test`.

This commit adds a test to the `wasmtime-fuzzing` crate as a
sanity-check that eventually a module is generated requiring all of the
features that wasmtime supports. This is intended to be another
double-check in the process of enabling a proposal in Wasmtime by
ensuring that the feature is added to this list which then transitively
requires that fuzzing eventually generates a module needing that feature.

cc bytecodealliance#9449

… from host APIs (bytecodealliance#9454)

* Add support for initializing/getting/setting `funcref`s in GC structs from host APIs

We implemented support for `funcref`s in both Wasm and host APIs for arrays, but
somehow only implemented support for `funcref`s in structs for compiled Wasm
code, and mistakenly forgot about them for structs and host APIs (and things
that use host APIs, such as const expressions).

* fix clippy

…)` instances (bytecodealliance#9455)

Move everything into the same location about what features are enabled,
which are disabled, and such. Also statically enumerate all the features
that wasm-smith enables for us and acknowledge that here too.