Use precise alias regions for statically-known entity imports

[fitzgen]

Accesses of statically-known globals, memories, and tables now use
AliasRegionKey::Defined{Global,Memory,Table} rather than the conservative
Public{Global,Memory,Table} region shared by every entity of that kind which
crosses a module boundary.

However, unlike known_imported_functions, this requires an extra condition:
every module that ever imports an entity must always import that same
entity. Otherwise a function that accesses, e.g., a memory via the conservative
region could be inlined into one that uses the precise region, and accessing the
same bytes through two different alias regions is invalid and leads to
miscompiles. That is, all of the importing modules and the defining module must
agree on the alias region.

Depends on #14114

[alexcrichton]

Thinking about this analysis done here I'm worried about the case where a module imports something and reexports it, although I can't quite place my finger on why so I wanted to ask about that. It seems like an import could be considered unambiguous but then an export could be considered ambiguous, but in that scenario we'd want the import to additionally be considered ambiguous. Does this handle that sort of case already?

[fitzgen]

@alexcrichton good catch, there was indeed a bug with re-exports. I've fixed it and added .wast tests that will fail when run with inlining enabled (e.g. by the wast-file fuzzer) if we mess up our alias regions in this way again (and checked locally with wasmtime wast -Cinlining=y that they failed before the fix and pass afterwards).