Support CommonJS loading from ES6

This resolves https://github.com/google/traceur-compiler/issues/818.

The following use cases become possible:

* Compiling a NodeJS project from ES6 into CommonJS for hosting on npm.
* Writing ES6 that imports from NodeJS builtins
* Writing ES6 and compiling into CommonJS to be browserified into the browser, sharing dependencies with browserify modules.
* Running `traceur app.js` and running an ES6 app that loads both CommonJS through the node module system and ES6. (correction - actually I'm not sure if this use case applies, but it is a related compatibility).

The benefit of combining CommonJS loading through ES6 imports, is that this is what the dynamic module loader is designed to handle. The way this implementation runs, it is fully-compatible with the dynamic module loader as well.

Since CommonJS already uses the runtime for destructuring, this is implemented with a runtime function. It also allows the implementation to be improved when a `Reflect.isModule` function is available or similar for true ES6 environments.

I feel pretty happy this is the right direction for this interop, and note that this interop exists regardless of our support, but as a broken interop otherwise, as discussed in https://github.com/google/traceur-compiler/issues/818.
I was also tempted to do this type of inlining, but there is an aesthetic argument in play that I'm trying to cater too here.

Note that CommonJS modules use destructuring, so there is often a runtime dependency on `$traceurRuntime.assertObject` anyway. So I think we either need to work to removing this as well in the process, or stick with the runtime approach?