Remove the `global_value` CLIF instruction

[fitzgen]

This would force us to translate all unnecessary uses of ir::Global into regular CLIF instructions.

Note: We have to keep cranelift_codegen::ir::Globals around for special things like the stack limit check, which are not (and can't ever really be) represented in regular CLIF instructions, since they happen inside of function prologues or what not.

However, we end up using ir::Globals in lots of other places where we could just use regular CLIF instructions instead. For example, we use them to represent Wasm globals in our Wasm to CLIF translation layer. This is annoying because now we have to fit Wasm globals into different kinds of ir::Globals, and it would just be easier to emit the CLIF instructions to get/set the Wasm global directly. These unnecessary ir::Global uses just introduce extra abstraction layers that don't buy us anything, add instructions that require legalization processing in the mid-end, make it harder to follow code through the compiler pipeline because there are extra and unnecessary rewrites, etc...

I propose that we remove the global_value CLIF instruction (the instruction that turns an ir::Global into an ir::Value). Every use of global_value could instead just be the constant or (chained) load that it would otherwise be legalized into, and emitting that already-legalized code will be easier to follow and also mildly more efficient since it doesn't need that legalization anymore. It also means we can remove the associated legalization code.

[cfallin]

Strong support for this one! I've mentioned previously my understanding of the rationale for global values: to express values that need to be used in parts of the IR outside of instructions: e.g., the example you give of stack limit checks; also the size argument for dynamically-sized vector types. There used to be more such cases -- e.g. when heaps were a core-Cranelift concept. But there's no reason to restrict ourselves to the static sublanguage for values that are only used in normal program flow.

If we make this cleanup, it's tempting to wonder about the remaining uses of GVs themselves: dynamically-sized vectors have stalled, and it's unclear if we want to keep them long-term (or perhaps we could have a more scoped mechanism for them); stack-limit checks are always going to need support as long as Wasmtime supports no-virtual-memory environments but again maybe there's a way that we can scope the feature down to describe exactly what Wasmtime needs. (This could include changing Wasmtime's strategy too, e.g. pass the limit in a register and force interruption use-cases to use epochs rather than stack-limit changes, but that's a larger discussion.)