Investigate ES6 modules as our internal components

(Forked off from https://github.com/kripken/emscripten/issues/5794#issuecomment-346166202 )

As a long-term goal, it would be nice if emscripten output

* Fit in with node.js packaging in a natural way.
* Fit in with ES6 build system tools.
* Were overall as modular as possible.

Those might be achievable by splitting all or most of the JS we currently emit into ES6 modules. So the GL code might be such a module, etc. Less obvious how the runtime would, but could be possible.

This is not something we can do right now (in particular, not all browsers support ES6 modules, and wasm integration there is farther out), but in the linked issue above we discuss various refactorings, and it could be useful to keep the ES6 modular goal in mind, so that we are working towards that.

We'll need to do a bunch of investigation along the way, including

* Code and compile time implications of such changes. In theory compile-time tools can merge ES6 modules and remove the overhead (of imports etc.), but we should verify that (e.g., it might remove imports but leave more JS objects or IIFEs around as "namespaces"), and we'll need to see how fast those things are.
* How such modularization would work with our various build flag options (separate module for GL vs GL emulation? or at compile time like now? etc.).
* How it would fit with our EM_ASM and js-library options.
* Look at Rust's new approach to how JS and wasm integrate. Still early there, but we should see what they do and how it goes.