Prepare for 0.4.0.M1

Docs tweaking and package info renaming in README.md
My point is that this doesn't need to be part of the spec. It suggests a need for a `Publisher` to have state, but it doesn't. The spec is now using wording like "`shut-down` state" which makes it into a formal thing, but nowhere have we formalized `Publisher` "states" and I suggest they are not needed. It is all covered by 1.14 that allows a `Publisher` to reject subscriptions. A `Publisher` is completely capable of being stateful or stateless. We should not have wording in the spec that suggests particular states for a stateful `Publisher`. It is over-prescriptive.

For the "hot" example you give, look here: https://github.com/reactive-streams/reactive-streams/blob/master/api/src/examples/java/org/reactivestreams/example/multicast/StockPricePublisher.java

This implementation shares an underlying resource without the `Publisher` itself ever having "state", and certainly not a "shut-down" state. 

It can do `refCount` and start/stop the underlying source if it wants, but again, this does not require a `Publisher` being involved, which is in this implementation just a factory. 

We already permit unicast and multicast, and we permit a `Publisher` rejecting subscriptions. I suggest we leave it at that without overly prescribing what states exist, or if they even do exist on a `Publisher`.