Global and function import model

[dschuff]

Currently Binaryen IR has a list of functions; a list of globals; and a list of imports, which may be functions or globals. Calls target one or the other (call vs call_import), and every operation that references a global has to explicitly check for both module-defined globals and imports.
That architecture dates back to the pre-release wasm 0xb format. With 0xc and beyond, wasm's model has a single index space including both imported and locally-defined functions (and likewise for globals) and only one call instruction. This is conceptually simpler, and would probably be simpler in Binaryen IR (as well as lining up directly with wasm).
In Binaryen functions and globals use names instead of numbers, but we could just use a single namespace for local and imported functions (and likewise globals) and it could work pretty much the same. The way Binaryen handles memories and tables was (re)written after 0xc and lines up better. Those just have the same object for imports and locally-defined things, with a boolean that indicates whether it's local or imported. We could do the same for functions and globals (there would just be a list of them instead of one per module). Separately we could just keep the list of imports as well if it's useful (it's possible that it's not useful; i.e. the only place the actual list is needed is on serialization, at which point we could just walk the full list of globals to create it).

A while back I started to implement mutable globals and got sidetracked because I wanted to fix this, but didn't get it finished. #1644 reminded me to bring this up again. That PR makes mutable globals work in the current system, and it seems ok in that context (I'm not going to block it by asking that @jayphelps rearchitect the IR, unless it's just easier to do that first), but we should still make this change soon anyway.

[kripken]

Sounds good. Yeah, it would be simpler to just have a list of functions and globals, and info inside them saying if they are imports or not.

One minor thing to consider here is that unifying Call and CallImport may have implications for the optimizer. Specifically, Binaryen lets you optimize a function by itself (before the module is complete), and having separate Call/CallImport nodes meant that we knew the difference at that time. I don't think there's an actual problem to make this change, but wanted to point it out since I might be missing something.

[dschuff]

At function creation time, if you knew enough to know whether to generate call or call_import, then when it analyzes a call, the optimizer should also know whether it calls an import or not, right? so it should be able to do the same optimization. Are parallel function passes allowed to read the Module object?

[kripken]

It's a little subtle - parallel passes are allowed to read global state except for functions. The rationale is that you build the other global state quickly, then start to add functions, and optimize while you add them, so checking the list of functions is the only thing changing and that must not be read.

Thinking more on that, a unified list of functions and function imports does imply that we can't check that list in a parallel pass - so we would actually lose that information (the frontend might know, but can't encode that in the single call node). I suppose we could save it in a data structure on the side. In any case, so far I can't think of a concrete reason we'd actually need that information.