TopN performance improvements

##How the aggressive loop unrolling works:

* Each aggregator's offset into the stream is calculated and stored
* Most queries have fewer than 8 aggregates, this allows them to be executed in a simple switch statement. (See [Duff's Device](http://en.wikipedia.org/wiki/Duff's_device) for more info on this type of approach).
* If there are more than 8 aggregates, then they are executed in blocks of 8, with the "leftover" non-divisible-by-8 aggregates being evaluated first.



Re-factor scanAndAggregate in PooledTopN

* Loops are now a little bit tighter when looping over aggregates. This will hopefully assist in loop execution optimization.
* Pre-calculated the aggregate offsets instead of shifting them during runtime.
* Cursor loop could use some TLC, but would require a massive refactoring on how TopN queries are executed.
* Any potential modifications to query workflow need to account for Stream vs Batch data, and that not all data will be array backed that comes in.
* Changed looping to attempt to do 8 at a time for both aggregates and dim values
* Any dim value collection or aggregate collection with less than 8 at a time, or the remainder of values which are not evenly divisible by 8, has values serviced by a SWITCH statement rather than looping anything.

Change data storage type in TopNNumericResultBuilder.

  * Use PriorityQueue to store
  * Checks to see if should even bother adding to Queue before adding.
  * Re-orders Queue on build() call.
  * Ideally the order would be directly preserved on build(), but this is a close second.

General performance improvements:

TopN multivalue multi aggregate: just shy of 30% faster

TopN multivalue single aggregate: just shy of 5% faster
empirically it was still faster to have a switch case for up to 5 rather than just up to 4. Of course those types of decisions may have to be revisited with different JVM or hardware configurations.