First refactor for WebIDL bindings

[alexcrichton]

This commit starts the wasm-bindgen CLI tool down the road to being a
true polyfill for WebIDL bindings. This refactor is probably the first
of a few, but is hopefully the largest and most sprawling and everything
will be a bit more targeted from here on out.

The goal of this refactoring is to separate out the massive
crates/cli-support/src/js/mod.rs into a number of separate pieces of
functionality. It currently takes care of basically everything
including:

• Binding intrinsics
• Handling anyref transformations
• Generating all JS for imports/exports
• All the logic for how to import and how to name imports
• Execution and management of wasm-bindgen closures

Many of these are separable concerns and most overlap with WebIDL
bindings. The internal refactoring here is intended to make it more
clear who's responsible for what as well as making some existing
operations much more straightforward. At a high-level, the following
changes are done:

1. A src/webidl.rs module is introduced. The purpose of this module is
   to take all of the raw wasm-bindgen custom sections from the module
   and transform them into a WebIDL bindings section.

This module has a placeholder WebidlCustomSection which is nowhere
near the actual custom section but if you squint is in theory very
similar. It's hoped that this will eventually become the true WebIDL
custom section, currently being developed in an external crate.

Currently, however, the WebIDL bindings custom section only covers a
subset of the functionality we export to wasm-bindgen users. To avoid
leaving them high and dry this module also contains an auxiliary
custom section named WasmBindgenAux. This custom section isn't
intended to have a binary format, but is intended to represent a
theoretical custom section necessary to couple with WebIDL bindings to
achieve all our desired functionality in wasm-bindgen. It'll never
be standardized, but it'll also never be serialized :)

2. The src/webidl.rs module now takes over quite a bit of
   functionality from src/js/mod.rs. Namely it handles synthesis of an
   export_map and an import_map mapping export/import IDs to exactly
   what's expected to be hooked up there. This does not include type
   information (as that's in the bindings section) but rather includes
   things like "this is the method of class A" or "this import is from
   module foo" and things like that. These could arguably be subsumed
   by future JS features as well, but that's for another time!

3. All handling of wasm-bindgen "descriptor functions" now happens in a
   dedicated src/descriptors.rs module. The output of this module is
   its own custom section (intended to be immediately consumed by the
   WebIDL module) which is in theory what we want to ourselves emit one
   day but rustc isn't capable of doing so right now.

4. Invocations and generations of imports are completely overhauled.
   Using the import_map generated in the WebIDL step all imports are
   now handled much more precisely in one location rather than
   haphazardly throughout the module. This means we have precise
   information about each import of the module and we only modify
   exactly what we're looking at. This also vastly simplifies intrinsic
   generation since it's all simply a codegen part of the rust2js.rs
   module now.

5. Handling of direct imports which don't have a JS shim generated is
   slightly different from before and is intended to be
   future-compatible with WebIDL bindings in its full glory, but we'll
   need to update it to handle cases for constructors and method calls
   eventually as well.

6. Intrinsic definitions now live in their own file (src/intrinsic.rs)
   and have a separated definition for their symbol name and signature.
   The actual implementation of each intrinsic lives in rust2js.rs

There's a number of TODO items to finish before this merges. This
includes reimplementing the anyref pass and actually implementing import
maps for other targets. Those will come soon in follow-up commits, but
the entire tests/wasm/main.rs suite is currently passing and this
seems like a good checkpoint.

[alexcrichton]

Note that this is indicative of that there are actually a few subtle behavior changes in this PR. Some things aren't quite as "final" as they used to be, although I suspect that this is ok in practice basically everywhere.

[alexcrichton]

Ok! I've put this PR through its paces and I think this is ready to go. I suspect that there's at least one bug still lurking but I'm pretty confident there's nothing overly glaring at least.

[fitzgen]

Ok, here is my review for the first commit; going to get to the rest of them tomorrow :)

[fitzgen]

Want to add a find_by_name method to walrus::ModuleImports? Or file a good-first-issue.

Edit: filed rustwasm/walrus#84

[alexcrichton]

I filed rustwasm/walrus#86 for this as well

[fitzgen]

Ok all the rest of those commits were indeed much more manageable to go through, and I don't really have much to say :)

Looks good!

[fitzgen]

Is this better than using BTreeMap instead of HashMap?

[alexcrichton]

Eh I think it's sort of taste. I personally like to use HashMap as much as possible until proven otherwise, and then when it affects output either use a temporary BTreeMap or sort it like this somehow. It really could go either way though and I don't have a preference one way or another.