Bring back TCK for 0.4.0

Initial draft of 0.4.0 TCK.
Submitting this PR "early", as in it's not completely done, but I want to get your feedback as soon as possible. 

Please have a look at `PublisherVerification` and `SubscriberVerification` first - the specs are documented and link to the respective points in the spec. In a few places I would like to ask for clarification / check if the test checks what it's supposed to - these are highlighted with TODOs.

`IdentityProcessorVerification` delegates to subscriber and publisher tests, as well as contains some additional specs which I have not yet reviewed if they make sense under the 0.4.0 spec.

Related: We had a feeling with @drewhk that `2.12` would perhaps make more sense as a Publisher rule, since it's mandating some kind of behaviour on the Publisher side. Opinions?

Some initial ideas around https://github.com/reactive-streams/reactive-streams/issues/87 are also included in this PR, and I would welcome opinions about it. The idea is around `maxElementsFromPublisher`, which implementors can override, and then if it's 1 for example, but my test requires at least 3 elements, we can mark this test as skipped.

In order to run the TCK against your implementations (please do report if I got anything wrong) you can publish it locally: `sbt publishLocal` (to local ivy repo) or `sbt publishM2` (to local maven repo).

This PR aims to eventually resolve https://github.com/reactive-streams/reactive-streams/issues/85

Thanks in advance for your feedback and comments!

Depends on:
- https://github.com/reactive-streams/reactive-streams/pull/93
True, my worry is that:

* we have `errorStatePublisher`, it triggers `onError` right away, instead of `onSubscribe` even -- which is described in `1.12`. I can swallow this, but I never got a subscription to try triggering `request()`.

So we'd end up testing `1.12` again here, instead of what I'd like to try testing here:
* get subscription
* `request` some, start the flow of data,
* get the `onError`, and verify that after this the subs does not get any more onNext signalled.

It's a bit that is different is that the 2nd scenario actually has data flowing initially. 
Maybe I missed how I could test this with already available tools though?