Reactive Slick

Here's the ongoing work on Reactive Slick.

/cc @cvogt for review later
The TCK doesn't test this scenario. Otherwise this test would have to fail for the current implementation here.

You don't need a memory barrier between individual elements in a batch because you call `onNext` synchronously. If the Subscriber wants to process the signals asynchronously, it is his responsibility to publish them properly.

With database I/O, I doubt that it makes much of a difference for the performance, but in a micro benchmark (https://gist.github.com/szeiger/b4ab7a6fff469be91967) the effect is *very* noticeable (with Java 7 on my MBP, after some warm-up cycles):

```
[info] Local          : 30ms
[info] Local Counting : 59ms
[info] Atomic Counting: 1034ms
```

Processing demand asynchronously would require a different (i.e. less efficient) synchronization scheme than the single AtomicLong that I use at the moment. Keeping two different counts is indeed what the current implementation does but the `requested` count is only touched in `request()` and it doesn't need any synchronization.