移除对 RxJS（即可观测库无关）的依赖

While we love RxJS, there are indeed a large number of competing stream libraries. The paradigm this library intends to provide is not actually tied to RxJS, so other "ports" of redux-observable will eventually continue to pop up. For example, redux-most. IMO, we should at least consider, "what if redux-observable didn't actually depend on RxJS at all?". We use a couple of RxJS operators internally right now, but mostly out of convenience. At first blush, it seems we could get away without it. We would want to take great care that we're not reinventing too much of RxJS--it may turn out that reducing the number of RxJS operators we use internally is enough to no longer make it a peer dependency and instead, depend on it explicitly as merely an implementation detail, though even this isn't ideal because all of RxJS v5 is still in our node_modules and at least one prominent Electron user has reimplemented redux-observable for v4 for that reason alone. I think the biggest question is actually how the ergonomics to RxJS might suffer in exchange. I do want to lean on the proposed ECMAScript TC39 Observables spec as the core, so regardless of the stream library you wanted to use, it would have to support the Observable spec, or there at least be a way for someone to convert between them. most.js, xstream, kefir already support it, with bacon.js support in discussion. There would also be a question of documentation complexities. I'm not sure how maintainable it is to make separate versions of the docs for each stream library. In practice, it would likely end up being "RxJS v5 examples are documented by us, PRs for others are happily welcome" until we could make relations with other stream library users who would be willing to join some sort of "redux-observable core team". So I think in that case, everyone would want to use an adapter, even RxJS users.