Karma sharding g3v1x

This is prototype/example code.

In this Travis run – <https://travis-ci.org/angular/angular.dart/jobs/33159766> – we can see that the Firefox tests take 2m30s to run as opposed to the 25m [in a regular run](https://travis-ci.org/angular/angular.dart/jobs/33152203).

There are actually 4 jobs running Firefox karma in parallel, each running 1/4th of the normal tests.  The output is mingled but ok.

```text
Firefox 30.0.0 (Linux): Executed 409 of 409 SUCCESS (2 mins 16.855 secs / 2 mins 15.357 secs)
....................
..................................................
........................................
..................................................
Firefox 30.0.0 (Linux): Executed 410 of 410 SUCCESS (2 mins 14.153 secs / 2 mins 12.805 secs)
..................................................
........
Firefox 30.0.0 (Linux): Executed 408 of 408 SUCCESS (2 mins 34.253 secs / 2 mins 39.31 secs)
..................................................
...........
Firefox 30.0.0 (Linux): Executed 411 of 411 SUCCESS (2 mins 30.957 secs / 2 mins 29.93 secs)
```

This is how our traditional Firefox runs look:

```text
Firefox 30.0.0 (Linux): Executed 1565 of 1565 SUCCESS (25 mins 34.727 secs / 17 mins 13.582 secs)
```

In this sharding example, we're running dart2js/transformers 4 times because we're running 4 instances of karma.  This is too much for the tiny VM boxes.  There should be no difference in the dart2js output for each shard – only the config is different – so we can eliminate this issue and keep our parallel success times.

This PR needs to be cleanup up / addresses these points and stick chrome back into the rotation (chrome can be sharded too – but only if once we reuse the dart2js outputs for the shards.)
May be we should find something more generic than "_travisMode" ? ie this is not limited to travis