Improvements to module name generator, registered ES6 modules support and updated traceur

The following text has been copied from the following issue: https://github.com/aaronfrost/grunt-traceur/issues/45

---

Currently the module names have their first path separator in name replaced with an underscore (_), which complicates usage of relative path imports between modules with the `modules: "register"` option.

I propose removing the `path.sep -> _` replacement (applied only on the first one? why??) and adding options for specifying a module name prefix to strip and module name prefix to apply after stripping.

Additionally, the traceur version referenced in this project is old, and because of this the type assertions do not work as they should.

I have implemented all these changes in a fork available here: https://github.com/jurca/grunt-traceur
I would like to suggest pulling my changes to this repo.

With the options I added, it is still possible to simulate the old (current) behavior, keep the compatibility with commonjs and amd and add better compatibility with ES6 System module loader.
Actually, yes. Let's suppose someone has the following code organization:
```
src-backend/myproject/
src-backend/myproject-mock/
```
The `src-backend/myproject-mock/` would be a mock implementation of classes in `src-backend/myproject/` for use in tests.

There would naturally be two different grunt tasks for building either the real or the mock implementation. It is only reasonable to share the common configuration items in the general options of the grunt-traceur task.

If the developer would fail to specify the correct `stripPrefix` option for the mock implementation (for example due to re-organization of project files), the condition proposed by you would match the prefix even in `src-backend/myproject-mock`, which would result in a really weird module names. Using the matching condition proposed by me would not strip the prefix in the module names, which would still generate odd module names as result, but it would be much clearer from the resulting module names what went wrong, helping the developer fix the configuration issue more quickly.

The motivation is basically defensive programming and making the plugin more "idiot-proof".

...on a related though: may the options should be named `stripPathPrefix` and `addPathPrefix`, or simply `stripPath` and `addPath` to make it clear they refer to module name *path*.