Validate global imports

[stevenfontanella]

• Add a RuntimeGlobal class to wrap the global's runtime value as well as its definition so we can check its type + mutability for import validation
  • Global imports are invariant for mutable globals and covariant for immutable globals:
    . Mutability must match as well.
• Fix old_import.wast to account for instantiations which should correctly fail. This test is now mostly the same as test/spec/imports.wast, but there are small differences so I plan to keep it until the upstream testsuite imports.wast passes.

Example error message:

[trap Imported global Mref_ex.g-var-func with definition (global $global$6 (mut (ref func)) (ref.func $f))
 isn't compatible with import declaration: (import "Mref_ex" "g-var-func" (global $gimport$0 (mut funcref)))
]

Part of #8261.

[tlively]

Does this mean the test is wrong or that our implementation is wrong?

[stevenfontanella]

Our implementation is wrong, table types should be invariant for imports but I implemented them as covariant (same mistake as Java): link. I'll address this in the next PR.

[tlively]

Can we have this be a pointer to the underlying definition owned by some defining module? It's a little weird to have a Global that is just hanging out and not owned by some module.

[stevenfontanella]

I think that would make the lifetimes/pointers more complicated. Now we have

ModuleRunner -> RuntimeGlobal

If we made the global a pointer, it would be

ModuleRunner -> RuntimeGlobal -> ModuleRunner -> Module

Basically the RuntimeGlobal would have to point back at the Module owned by ModuleRunner. In practice everything will live as long as the ModuleRunner, but it would be hard to tell from reading the code and if more complicated cases some up.

I also think that it's ok for a Global to stand on its own. It might be instantiated in different modules, so the Global itself isn't tied to a particular instance, only the RuntimeGlobal is. Does that seem reasonable?