Cranelift: split out a "settings" / flags infrastructure that works without the compiler proper

In #3897, we discovered that Wasmtime's checking of a serialized/AOT-compiled module's flags for compatibility was not running if the runtime was not built with the compiler included. #3899 hardcodes some checks in a way that still works without Cranelift, so solves the immediate problem, but is not an ideal fix.

Ultimately we should be able to talk about the settings/configuration for the compiler without actually including the compiler itself. In the same way that `Target` is a type defined in a separate crate (`target-lexicon`), we should create a new crate `cranelift-settings` that lives at the bottom of the crate dependency DAG, and can be used without Cranelift itself. (It will probably depend on the settings stuff that is generated by `cranelift-codegen`'s meta crate currently, so we'll have to figure out how to split things apart appropriately.)

This crate should have a way of comparing flags as well. Each flag has some property of "ABI compatibility" which is a sort of subtyping relation: for some flags, code generated with that flag taking on one value is compatible with the runtime assuming the flag has another value. For example, optimization level or regalloc selection don't affect the generated code-to-runtime interface. Nor should settings that affect whether certain ISA extensions are enabled. But, for example, the existence of safepoints in the generated code *does* affect the runtime; if code is generated without these, its execution will be incorrect if the runtime is providing reftypes.

So we should have a `CompilerFlags` and it should support a partial order relation which computes this compatibility.

Then, the `cranelift-native` crate can generate some flags that correspond to the maximum CPU features on the host, and `wasmtime-cranelift` can also generate a `CompilerFlags`, indicating which flags are required for a given Wasmtime config (e.g., safepoints, or fuel or epoch instrumentation, etc.). We should also have a way to merge flags; this is a "meet" on the lattice induced by the partial ordering relation above. (Slight subtlety: the lattice is a product lattice of an individual lattice per flag; each individual flag also needs a "top" (don't care) and "bottom" (conflict) value.)

Then finally, wasmtime's compatibility checks and compile-time flag selection can use this infrastructure, rather than the hardcoded feature-compatibility matrices encoded into the `Engine` and serialization logic.