Compiled Module loading should check isa flags against host cpu

[pchickey]

Loading a compiled module into wasmtime may mean the Module was compiled on a different machine. Wasmtime does not provide a mechanism to make sure the set of flags on a compiled module is compatible with the CPU that the compiled module will be executed on.

Presently, when wasmtime loads a compiled Module (e.g. Module::deserialize_file), the isa flags in the loaded module are only checked when cfg(compiler):

wasmtime/crates/wasmtime/src/module/serialization.rs

Lines 316 to 321 in 8023026

	#[cfg(compiler)]
	{
	let compiler = engine.compiler();
	self.check_shared_flags(compiler)?;
	self.check_isa_flags(compiler)?;
	}

This check doesn't even perform precisely what we want - it will determine if the Engine's flags are compatible with the loaded module, which do not necessarily match the host cpu.

So, I propose the following additions to wasmtime:

1. wasmtime::Config should have the target and cranelift_flag_set methods available even when the feature cranelift is not enabled (e.g. in runtime-only mode).
2. wasmtime::Config should have a setting which mandates that Engine construction validates those target and cranelift flags against the host cpu. This needs to be configable so that an engine Engine can be used for cross-compilation.
3. When loading a compiled Module, the isa flags should be checked against the Engine settings even when cfg(compiler) is not enabled.

[akirilov-arm]

Concerning item 2, there is a subtlety - it might be acceptable to have some discrepancy between the features supported by the host CPU and those used by the compiled module if the difference consists of features that are backward-compatible. Examples are Pointer Authentication and Branch Target Identification from the Arm instruction set architecture (which I am discussing in bytecodealliance/rfcs#17 and have prototyped in PR #3693) and I believe that the ENDBR instruction introduced by Intel CET behaves similarly.

cc @abrown

[alexcrichton]

I implemented #3899 in a way that can accomodate the pointer authentication bits since the query made is "is this feature compatible with the native host" so there's room to say whether or not pointer authentication is enabled that's always compatible with the native host (possibly with extra handling to enter/exit the module in a different fashion if it's enabled/disabled).