Polyfill upgrade

@addyosmani I'm really glad to be able to collaborate on the project, and ensure it has a proper home! If you want to move it over to a custom org, that is fine with me.

I've taken the changes from https://github.com/guybedford/es6-loader and refactored them back into this code base, with some additional updates and code style changes roughly matching the initial code structure here.

I haven't updated the readme, but let me know if you would like me to. The material is currently at https://github.com/guybedford/es6-loader and the article at http://guybedford.com/es6-modules-today gives more background.

### Specification Notes

The polyfill is implemented exactly to the specification now, as far as I am able to tell, except for the following:

* The `extra` metadata property is not yet handled in the resolve, as I can't tell what happens to this.
* The `fetch` function is given a different specification between the prototype (`Loader.prototype.fetch`) and loader instance (`options.fetch`). Since instance functions are provided on the instance object as in the @wycats essay (`System.normalize`, `System.fetch` etc), there seems to be a conflict between these.
* The `evalAsync` function doesn't yet throw an error when exports are present, which should be the case.
* The `ToModule` function isn't implemented, but should be simple. I just couldn't tell if this was to be created at `window.ToModule` or `Module.ToModule`.
* The intrinsics encapsulation is a tricky one to polyfill, but I have done my best based on a global prototype chain behaviour, where `global.__proto__ == intrinsics`. And `intrinsics.__proto__ == window`. All code is evaluated with the `window` and `this` properties referencing the `global` allowing full global encapsulation.

### Syntax Parsing

The ES6 Harmony parser is being used to do parsing, loaded only when necessary. This parser still uses an older syntax, which is currently the major critical issue to sort out for this polyfill.

The issue tracking this is here - https://code.google.com/p/esprima/issues/detail?id=410

There may be parser alternatives as well, and I would be open to suggestions here. Perhaps using a JISON-generated parser as in https://github.com/xcambar/harmony-parser, or even just a custom lexer.

### Tests

I have been testing this against the test suite of a RequireJS-style loader I have been working on. It is passing all these tests, but the test suite isn't suitable for here. Happy to assist getting tests together if a methodology is suggested first.

The informal tests I have been running are here - https://github.com/jspm/jspm-loader/tree/master/test.

A well-designed test suite would be incredibly useful to ensure that future browser implementations behave similarly to the polyfill, and would form a great benchmark when detecting implementations in future. Thus I think it is quite important to get this right.

I look forward to working on this further.