Unclear how to set Wasmtime inlining options from `Config` API

[cfallin]

Currently, the Config API has only compiler_inlining, which flips a global flag to enable the inliner, but its behavior is governed by more fine-grained flags.

Some of these flags are exposed as hidden "Cranelift flags" interpreted by wasmtime-cranelift here. These flags are set at least by the fuzzer here. That match in the setter in turn alters the tunables that are contained on the wasmtime_cranelift::compiler::Compiler.

However, the actual inlining decision is governed by the Tunables held on the Engine. These Tunables are passed into the compiler here, when using the configuration to build the compiler object. However, note that the flow is one-way: the set_tunables trait method takes a Tunables by value, i.e., copies all the tunable knobs once at that time. The copy is then altered in the next few lines as the compiler flags are applied, but the original that ends up on the Engine never is.

It's still a bit unclear to me how the fuzzer ultimately is able to set up fuzzing of inlining appropriately, but when I try to get intra-module inlining to work with

config.compiler_inlining(true);
unsafe {
    config.cranelift_flag_set("wasmtime_inlining_intra_module", "true");
}

I find that intra_module_inlining when queried by the inlining heuristics is still at its default WhenUsingGc rather than Yes. I had to add a Config::compiler_force_Inlining() method as a hack in #11769 to allow for testing, but we should probably support the hidden flag properly from the Config API instead. It's unclear to me what the right fix should be: either alter the plumbing so tunables updates can be made by the compiler (should set_tunables take a mutable borrow of the Tunables, held only while the builder is alive, and we can then move the clone into the build step?) or by adding a more first-class way of setting these inlining heuristics on the Config.

cc @fitzgen