Prepare for 0.4.0.M1

Docs tweaking and package info renaming in README.md
Sorry yes I meant `Processor`. The "upstream" may only mean the 3rd processor in a chain of 5.

```
origin.p1.p2.p3.p4.p5.subscriber
```

If p3 fails and emits `onError` down, it also needs to `cancel` the `Subscription` upwards – or it lets the error throw, but that's bad form as there is no guarantee over async boundaries that a thrown exception will gracefully be handled.

An example of p3 failure is if it is a `map` that takes a user function. Since a user function is provided it may fail in the `onNext` (since user code fails). When it catches the exception in its `onNext` it then signals `onError` down. 

```java

class MapProcessor {
  void onNext(T t) {
    try {
          downStream.onNext(userFunction.call(t));
    } catch(Throwable t) {
        onError(t);
    }
   }
}
```

What will our spec say on when the `Subscription` should be canceled so the upstream stops sending data?

In Rx we don't make every `Processor` do this, we let them just call `onError`/`onComplete` and then the final `Subscriber` (the one provided by the user) will call `cancel` back up the chain to ensure everything has a chance to be cleaned up regardless of where the terminal state was signaled from. There are some cases where we do this eagerly (the `take` and `merge` processors for example).