remove unused extension. add new signature for observableExtension
Replace PooledDispatcher with a ThreadPoolExecutor-based Dispatcher
Merge pull request #5 from wilkinsona/thread-pool-dispatcher

Replace PooledDispatcher with a ThreadPoolExecutor-based Dispatcher
Use ReadWriteLock rather than synchronization

Access to CachingRegistry will typically be very read heavy with few,
if any, writes occurring after initial setup has been completed.
Therefore, it's a good candidate for using a ReadWriteLock, which
allows parallel reads, in place of standard synchronization which does
not.
Merge pull request #6 from wilkinsona/cache-registry-rwl

Use ReadWriteLock rather than synchronization
Improve ThreadPoolExecutorDispatcher by using a RingBuffer to pool internal Task objects. The previous version was incurring massive GC overhead because of new object creation, so this RingBuffer object pool approach gets performance up to near the BlockingQueueDispatcher.
Merge branch 'improved-threadpool-dispatcher'
Tweaks to performance and backlog numbers based on profiling data.
Merge branch 'performance-tweaks'
Notify using an Object, not a Selector

Previously, a Selector was used both to register interest in Events
and to key the notification of a new Event. This was somewhat
confusing as the two uses were different, and it perhaps didn't make
sense for a Selector to be used in both places.

This commit updates notification to take an Object as the key, while
retaining the use of Selectors for registering interest. As part of
this change, the tracking of usage counts has been moved from
Selector into CachingRegistry where they're used for load-balancing.
This was necessitated by stopping the use of Selectors for
notification. It has the benefit of improving the separation of
concerns - a Selector, that has no knowledge of load balancing, no
longer has to track usage count which is only used for load balancing.

The cache of matching registrations is now a Map of notification key
to registrations. It should be noted that, for this to perform well,
notification keys must having fast hashCode and equals implementations
Merge branch 'notify-with-object'
Based on the latest changes to change notify(Selector) to notify(Object), updated the way headers are handled. Introduced a HeaderResolver abstraction that a Selector provides to a caller that is responsible for parsing the key object and returning any pertinent headers. The Dispatchers were then updated to accommodate this new pattern.

Also renamed Tagable to Taggable and updated references.
Ignore Structure101 files.
Change SelectorSpec to use the headers as the source of the resourceId to ensure that a test covers setting of headers from selector matches.
cleanup Consumer
compiler issue
the ultimate fix ...
Remove vestigal references to usageCount.
Drop iterations in throughput test from 10 to 3.
#7 Added debug-level logging when no Selectors are matched against the given key.

Also removed some vestigal references to cache freshening code that didn't work after the change of `notify` to accept Object. When a `refreshRequired` is noted, the cache is now naively dumped and has to be re-populated key by key. It's impossible to iterate over the existing Registrations and re-populate the cache because the key coming in might be different than the one in the cache. We simply take a naive approach to this and dump everything, letting `find(Object)` re-populate the cache for the given entry.