Implement SystemLoader constructor

This adds a SystemLoader constructor function used internally to inherit from Loader. `System` then becomes an instance of SystemLoader and `SystemLoader` is set as `System.constructor`. This way downstream code can do something like:

```js
class MyLoader extends System.constructor {

  locate(load) {
    return super(load).then(function(address) { ... });
  }

}
```

And doing so will have access to `super` and the like.

I also added in `esnext` to build this and use es6 classes. We talked about doing it this way and it is *much* more elegant in my opinion (just look at the minimal amount of code changes).

Let me know if this adds too much code or you don't like it for some reason and I'll implement this as regular old constructor functions, but I thought this turned out really well.

One thing to consider is that the tests were pointing directly to `lib/loader.js` and `lib/system.js` so I made a built version of each of those go to `dist/` as well.

Review this carefully because the requirements were spread out over various issues and personal discussions.

Fixes #199
How important is it that `loader.js` and `system.js` are loaded independently in the tests? Because currently I'm building those separately to maintain that behavior, but potentially this means the same polyfills would be in each file (messy). When we build the entire `es6-module-loader.js` we would only want them once, at the top of the file. esnext will do this correct, we just need a way to say "only inject the polyfills at the top", if you get what I am saying.