This removes the Runtime object from the generated code. Much of it was not needed at all, the rest is moved into plain JS functions in a new support.js file (which is easier for DCE to remove). This is something @juj suggested we do, and it helps with the goal of shrinking JS - this reduces code from a few % in something like libc++ to 15% in small hello world type things.

The history here is that in the early days I thought we'd have a coherent Runtime object, and it would be used at both compile time and execution time, sharing code between them. But with asm.js and wasm, we've been doing less and less in JS anyhow, so Runtime has made less and less sense. Also it turns out there are just a handful of methods we need both at compile time and execution time, at this point.

Another old idea was that we need to generate the runtime support dynamically, since we supported weird things like QUANTUM=1 (ints and pointers take one memory address location). That's why we had RuntimeGenerator and all that. But again, with asm.js and wasm, we really just support one type of memory, the plain C style. So it's easier to just write out those methods in support.js instead of generating them from a flexible template. This simplification may also help us in the future with more modularization of our runtime code (ES6 modules, etc.).

Breakage-wise, this does affect anyone that used anything on Runtime in a manual way: Runtime.X needs to change to just X. The Runtime object is sort of an internal implementation detail, so hopefully few people ever used it, but still, there's a risk. There are helper messages in assertions mode with some of the more likely candidates, hopefully that will help. Overall, I think this is unavoidable refactoring, and hopefully any inconvenience will be minor.