delay bundle skipping and compression handling

currently we usually block waiting for a remote response as soon
as we try to wrap the input stream in a decompression wrapper. this
is because the constructor sometimes tries to immediately read bytes
(like for a header or something). Bundle skipping is similar in that
it _would_ block given the chance. This change tries to move any
blocking network wait until after the source is pulled in turn from
the preOpen queue.

in order to take advantage of this change, jobs will probably need
to make sure meshy.stream.prefetch is set to true, preOpen is large,
and multiBundleReads is set relatively high (to try to pull as much
available data from wraps that have already paid the initial wait -
which tends to be the longest - before hitting the new wrap)
poll time cutoff and metric for the score cache
more logging for score cache
use linked queue instead of array backed

producers were hoarding the global lock the array version uses in
some cases
just choose the meshy host outside of the lock
removing cross-buffer max from task feeder

much less concerned about a couple thousand bundles on heap than
source feeder shutting down for 1000ms
different stealing method and linked queues

linked queues can get size() without locking. the stealing
variant is a little faster and adjustable
fix type typo
clean up for mesh2 source improvements et al

- cacheMap is accessed within the sync lock. It looks like that
would only ever manifest a problem in a NPE. That didn't occur
in testing, but better safe etc

- firstData / processing range re-implemented. It had been commented
out for convenience (it is pretty much unused). There is some more
explicit logic that makes it clearer what and when it is used for. I
kept it outside of the sync block, but changed the moreData variable
to volatile. This is kind of a hedge - it may not need to be volatile
because after all, setting firstDate to be not null isn't sync'd there
to begin with - I don't feel great about it being actually safe but that
is a problem for another time.

- some optimizations related to object creation. Fewer collections are
made, and more use initial capacity settings

- inverse lottery selection now takes a varargs param of primitive ints.
this helps a lot with the previous goal (collection creation), but also
makes it a bit simpler
Merge pull request #50 from addthis/prefetch-meshy2

Prefetch meshy2