Keep Config options for disabling compiled-out features

[Stebalien]

This patch keeps config options for disabling default-enabled wasmtime features, even when those features are disabled via crate feature flags. That way, these wasm features can be disabled by libraries even if the crate-level features are later enabled by some other crate in the build-tree.

Specifically, the following wasmtime::Config methods are now enabled regardless of compile-time features (removed dependency on the GC feature):

1. Config::wasm_reference_types.
2. Config::wasm_function_references.

The following methods are available on the wasmtime::Config type, regardless of the enabled crate features but will lead to runtime errors when constructing a wasmtime::Engine:

1. Config::wasm_threads.
2. Config::wasm_gc.
3. Config::wasm_component_model.
4. Config::wasm_component_model_async.

Finally, Config::parallel_compilation is defined regardless of whether or not the parallel compilation feature is enabled. However, without the corresponding crate feature, this config option is a no-op.

fixes #10454

[Stebalien]

I've tried to keep this change as minimal as possible and stuck to default-enabled features. I'm also happy to extend it to (any of the) features that are currently default-disabled:

• Config::async_support
• Config::wasm_function_references
• Config::wasm_gc
• Config::component_model_async
• Config::coredump_on_trap
• Config::wmemcheck
• Config::debug_adapter_modules

Also note: I didn't bother with cranelift/winch options. As I understand it, those will only matter if you actually use cranelift/winch so they shouldn't affect any creates that aren't using the cranelift/winch features.

[alexcrichton]

I think it might make sense to un-gate wasm_* configuration while you're here, but for the others I think it's ok to leave them as-is and deal with them as they come up later. Although if you'd like to handle them here that's also ok.

[Stebalien]

I've updated the PR per the new description to:

1. Always define the Config::wasm_* functions.
2. Allow setting Config::wasm_reference_types and Config::wasm_function_references (I'm not sure if this second one is correct, pending discussion in https://github.com/bytecodealliance/wasmtime/pull/10455#discussion_r2008436743).

[github-actions[bot]]

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to complete this check list:

• [ ] If you added a new Config method, you wrote extensive documentation for it.

  Our documentation should be of the following form:

  Short, simple summary sentence.
  
  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.
  
  Is this method fallible? If so, when can it return an error?
  
  Can this method panic? If so, when does it panic?
  
  # Example
  
  Optional example here.
  

• [ ] If you added a new Config method, or modified an existing one, you ensured that this configuration is exercised by the fuzz targets.

  For example, if you expose a new strategy for allocating the next instance slot inside the pooling allocator, you should ensure that at least one of our fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this configuration option in wasmtime_fuzzing::Config (or one of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this configuration. See our docs on fuzzing for more details.

• [ ] If you are enabling a configuration option by default, make sure that it has been fuzzed for at least two weeks before turning it on by default.

---

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the .github/label-messager.json configuration file.

Learn more.

[Stebalien]

Status update: I'm no longer working on the project that needed this PR so I'm going to close it for now. @alexcrichton thanks for taking the time to review this.

In case anyone else is interested in implementing this, the main remaining part is to resolve https://github.com/bytecodealliance/wasmtime/pull/10455#discussion_r2008491047.