When to remove support for disabling a feature?

Wasmtime has support for many proposals to the WebAssembly specification, including those that have since been "stabilized" by merging into the official spec repository. Wasmtime, however, still has knobs to disable these features such as:

* reference types
* bulk memory
* simd
* multi-value

Wasmtime also has support for proposals that were merged after the original release of the wasm specification such as nontrapping-fp-to-int and sign-extensions, but these proposals do not have `Config` options to disable them.

Most of the time support for disabling a feature is pretty easy to support as it's just a tweak during validation, but some proposals such as bulk memory [change some edge cases about behavior](https://github.com/bytecodealliance/wasmtime/blob/5d8dd648d71db22838e376b18ecd03b015a08485/crates/runtime/src/instance/allocator.rs#L410-L416) which means wasmtime has to switch on the appropriate behavior.

I don't believe that we have a preexisting policy on this so I wanted to raise this question: when do we remove the `Config::wasm_*` methods and unconditionally enable a wasm proposal? I would expect that the bare minimum is that the propposal is merged into the upstream wasm specification, but how much further than that do we wait?

I think that the answer here can be somewhat nuanced as well. For example multi-value probably doesn't make sense to keep around any more but reference types/simd may make sense since they're relatively risky proposals in terms of exposing bugs in Wasmtime.

I would personally propose that we remove a feature flag when it's both merged in the upstream specification and we feel that the implementation is stable within Wasmtime itself. I think we can remove the multi-value and bulk-memory feature flags for sure, and we can possibly remove the simd feature flag as well. For reference types though I think we'll want to keep that since we're less confident in the bug-free-ness of the implementation.