First attempt at lazy/multi-thread accumulator

Not entirely happy with the result because I had to move away bounded
queues, so no back pressure will be created on the producers.

This could be solved by distinguishing between immediate and background
requests for results.
Reworking the Accumulator API to expose a Scheduler rather than an Accumulator

This will allow the Accumulator to switch between bounded and unbounded
schedulers at the situation requires.
Switched to hybrid bounded / unbounded scheme

This allows immediate work in the reading thread to complete by using
the unboundScheduler, but will still allow for back pressure on the
worker threads by using the boundedScheduler.
Switching to unbounded scheduler in initialize
Switching to have ClassLocator-s produce ClassBlock-s rather than InputStream-s or InputStreamProvider-s to allow for more efficient use of IO and threads
Switching to have ClassLocator-s produce ClassBlock-s
Renaming Reactor -> Aggregator
Renaming Reactor -> Aggregator
Adding ability to introduced processing stages into aggregation pipeline
Adding processing chain capabilities

Introduced ability to create processing chains in AggregatingPipeline
(yes, another rename)
Moving AggregationPipeline into its project

- separating components part of aggregator out into multiple files
Moving aggregate pipeline into its OSGi bundle
Adding filter and transformed processors

- fixing bug with batching in chained processor
Adding in optimized versions of chained filtering and chained transforming
Removing unused variable
Using "? super" and "? extends" to make the generics more flexible
Removing the old Iterable abstractions

- Fixing up the aggregator tests
Renaming aggregate plug-in functional

Created JvmClassSet backed by the parallel Aggregator
Removing old locations
Adding newly required dependency on functional