Optimized, concurrent implementation.

A parallelized implementation using a work queue and a collaborative
blackboard-style data sync. This implementation dedicates a single
core to perform IO and uses all other available cores to run the logic.
Further, to keep GC times lower, the work queue is bound with a low
number and uses work stealing (really, caller-runs rejection) to prevent
heap blow-out.

This version exhibits highly optimized parsing methods that replace more
complex, yet inherently-readable methods. For example, the
Latin1AddressParser uses basic string logic instead of regex. This had a
very large (positive) performance impact on the overall CPU load and
processing time. Swapping this parser out with a more general-purpose
parser is a straight-forward task.

To decouple the actual data source format, the fairly straight-forward
concept of a TicketSource is used. This is a named wrapper around an
iterator and was implemented to quickly allow for data source swapping
(primarily used to test).
Potential IORE.
Comparator correctness.

The Comparator implementation needed to consider the street names in
addition to the values. This prevents duplicate streets containing the
same sum from becoming merged. While this impacted primarily the key
set, the get() operation would have behaved as expected (by accident).