Add ImportResolver interface and use it for global imports

[stevenfontanella]

Add an ImportResolver interface with some implementations to handle the spec interpreter and ctor-eval

• Removes coupling of imported names from the module they come from. This will allows us to provide special imports like the spec test module better which have some 'magic' e.g. for printing functions which can't be implemented in Wasm (globals remain the same because they still come from a real module which is better).
• Removes pointer chasing logic when resolving imported globals in both cases.
• Also allows us to relax ctor-eval and allow programs that import globals to be optimized more (as long as they don't try to evaluate imports) Try allowing globals to be imported in ctor eval #8168
• Fixes Segfault in ctor-eval when an imported global isn't used #8167

[tlively]

Usually we just say in a comment whether a pointer can be null. I'm not sure the extra type-level wrapper is worth it. Is this useful in your experience?

[stevenfontanella]

My thought is just to make it harder to miss by accident than a comment, and also to give us an easy way to migrate to 'real' nullability annotations in the future (we can just grep for the symbol instead of trying to find comments). Google uses nullability annotations and clang can apparently catch some bugs this way (TOTW 230 but this isn't accessible publicly).

I don't have a strong preference though, I agree that it's noisy to read.

[tlively]

@kripken wdyt?