Improve asynchronous Primitive creation

**Update:**
While the initial work on this issue is now in master and performance is much better, there are still several things we can do to further improve things. Here are some ideas that we can explore.
- [ ] Creating a general WorkerPool class, basically a threadpool for web workers. I could see this potentially being a singleton used to manage concurrency throughout Cesium (Geometry/Imagery/Terrain/etc..).
- [ ] Rather than pack all data into Float64Arrays, pack data into arrays of the same type. This will require a bit more bookkeeping, but shouldn't be too hard and will require less memory. This will also allow us to use subarray views in `unpackInstancesForCombine` rather than the overhead of creating lots of typed arrays.
- [x] The initial call to `createGeometry` is currently unpacked and can still adds a lot of overhead for certain types of Geometry; this can be fixed by having our Geometry know how to pack themselves or have them store there data in a typed array from the start for each transfer. #2342
- [ ] `combineGeometry` is still one big synchronous step and is just performed in a worker (rather than split up across several workers like `createGeometry`). I'm not sure if it's possible to refactor it in a way that allows for concurrency

**Original Issue:**
Currently, creating primitives asynchronously is much slower than doing it in the main thread. Some simple tests shows that a 1.58 MB GeoJSON file takes about 13 seconds to load asynchronously and only 4 seconds when synchronous. (in Chrome). These numbers are more event dramatic in Firefox, 6 compared to 35.

This is most likely due to a very chatty interface for offloading the pipeline and could be fixed with coarser interfaces.

Here's a profile of what the main thread is doing between "drop 10 megs of GeoJSON on globe" and "stuff shows up" when using asynchronous creation.


No files, tests, or entry points are named. Start by reproducing the asynchronous and synchronous GeoJSON loading comparison described in the issue, then determine which remaining idea to pursue: a WorkerPool, typed-array packing, or concurrent combineGeometry; done would require a defined performance improvement and verification against the selected scope.

Written by the indexing model from the issue text.