Reactive Slick

Here's the ongoing work on Reactive Slick.

/cc @cvogt for review later
As far as I can see, both Publisher and Subscriber must take care to never _locally_ violate the demand bound, meaning that requests can only be made once elements have been signaled, and elements can only be signaled once requests have been made. The synchronous request-from-`onNext` case exposes the need for the Publisher to decrement outstanding demand before signaling `onNext`, but the conclusion that this necessarily costs performance is false.

Exhibit A: AtomicLong in the Subscription
---

* `request` checks for overflow and fails if detected, otherwise `getAndAdd` the demand.
* Publisher keeps a local variable, not volatile or anything, that caches outstanding demand.
* When Publisher runs out of cached demand it retrieves fresh demand from the Subscription using `getAndSet(0L)`.
* Publisher goes to sleep when getting back zero.
* Subscription wakes up sleeping Publisher when it sees demand going up from zero.

Problem solved, right?