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
Also addresses "limited publishers"-  https://github.com/reactive-streams/reactive-streams/issues/87

Thanks in advance for your feedback and comments!


Depends on:
- [x] https://github.com/reactive-streams/reactive-streams/pull/93 Synch docs and examples with spec - request(long)
Oh, misleading method name I think. `3.5` is about: `Subscription.cancel MUST NOT synchronously perform heavy computations [...]`. I will move it to PublisherVerification but still not able meaningfully test this (exposing `long howManyMillisIsHeavyOperation` like we do for other "depends on impl" things doesn't sound right).