Merge pull request #139 from lburgazzoli/master

#138 reactor-tcp : TcpClientSpec.connect to support InetSocketAddress
Introduced a Sequencer for ordered and optionally persistent sequencing of events. It ensures that all events published on a key are ordered through a pluggable Queue implementation. The default is to use the same type of Queues for other places within Reactor (the LinkedTransferQueue e.g.).

A Sequencer can be configured to persist events by setting it's Queue to be an instance of one of the newly-introduced PersistentQueue implementations. There are two default impls: InMemory and IndexedChronicle. The former uses a Map and the latter uses a JavaChronicle IndexedChronicle to persist Events to the filesystem. It should be fairly straightforward, then, to create an instance of a PersistentQueue pointing to the same JavaChronicle in another process and read items from Queue that were published in the first process.
Update javadoc, add test for PersistentQueue.
Fixes for various Spring-related issues.

- Added a type attribute to the @On annotation for determining Selector type rather than attemptint to infer it or use sketchy shorthand functions in the expression.
- Changed the code around finding handler methods to better detect various situations.
Bug fixes to fix a failed test.
Changed the default reactor expression to be just "reactor", meaning an Autowired property on the bean named "reactor".
Make ConsumerBeanPostProcessor Proxy-aware.
Fixes #143

Added a PredicateSelector which makes it easy to use lambdas as Selectors.
Moved handler processing to after bean initialization rather than before.
Introduced a Sequencer for ordered and optionally persistent sequencing of events. It ensures that all events published on a key are ordered through a pluggable Queue implementation. The default is to use the same type of Queues for other places within Reactor (the LinkedTransferQueue e.g.).

A Sequencer can be configured to persist events by setting it's Queue to be an instance of one of the newly-introduced PersistentQueue implementations. There are two default impls: InMemory and IndexedChronicle. The former uses a Map and the latter uses a JavaChronicle IndexedChronicle to persist Events to the filesystem. It should be fairly straightforward, then, to create an instance of a PersistentQueue pointing to the same JavaChronicle in another process and read items from Queue that were published in the first process.
Update javadoc, add test for PersistentQueue.
Fix a bug with generics use.
Fix a bug with generics use.
RoundRobinFilter read-write lock recheck.

According to `ReentrantReadWriteLock.java` javadoc, we should
```java
Recheck state because another thread might have
acquired write lock and changed state before we did.
```
In our case if `usageCount == null`, than `usageCounts` map doesn't contain this key. But during 
```java
readLock.unlock();
writeLock.lock();
``` 
another thread can modify `usageCounts` map.
Seems like we need a recheck.
Merge pull request #151 from WonderBeat/patch-1

RoundRobinFilter read-write lock recheck.
Merge branch 'sequencer' of github.com:reactor/reactor into sequencer
Merge branch 'sequencer'
Fix bug in PersistentQueueSpec which was causing the get() to return null.
Fix Sequencer and PersistentQueue tests.
Fix PersistentQueue tests.