Only create ConcurrentState in a Store when CM async is enabled

[fitzgen]

Creating the default ConcurrentState will create a FuturesUnordered which will allocate. By making this state optional, we can keep making progress on #12069, and put off dealing with FuturesUnordered until when we are ready to try and make CM async code handle OOMs.

[fitzgen]

So I got things working, but I had to effectively turn cfg(feature = "component-model-async") from being a static, compile-time only feature to also being a dynamic, run-time feature. @alexcrichton you probably have opinions here.

[github-actions]

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.

  Details

  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.

  Details

  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.

---

Details

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.

[dicej]

LGTM, thanks.

Regarding the WAST test failures: now that the component model combines resource, task, thread, future, stream, and error-context handles all into a single table, tests involving those handles can be sensitive to whether or not e.g. a thread handle has been implicitly allocated as part of a call. For example, the first resource handle created by a guest will have a value of 1 if a thread handle was not allocated (i.e. because CM concurrency is disabled), but it will have a value of 2 if a thread handle was allocated. Also, Wasmtime makes the distinction between "not a valid handle at all" and "a valid handle, but not of the expected kind (e.g. a thread handle being used as a resource handle)".

I made this update as part of #12379; I suspect we'll need to do the same here. In some cases, that might mean explicitly enabling CM async for a given WAST (assuming it's been written with the assumption that a thread handle is allocated for each guest call). In other cases, it might mean changing the expected trap message and/or expected handle values. I can tackle that, if you'd like.

[fitzgen]

Thanks! Flagging the two offending wast tests as requiring CM async was straightforward and resolved the issues

[alexcrichton]

How come this was enabled? For debugging, or intentional?

As an unstable feature this is something I'd ideally like to keep turned off until component-model-async is ready

[fitzgen]

wasmtime serve and wasi-http unconditionally use the concurrency machinery today. We don't have a separate switch for the internal concurrency machinery vs the Wasm-facing component model async feature. Probably we need something like GC_TYPES, I suppose.

[alexcrichton]

Hm ok yeah I think we'll definitely want something disconnected from wasm feature validation for this. I'll work on that.