Integrate Maybe and Single into Observable. *** DO NOT MERGE

[abersnaze]

I've been working on the this for too long in the background and want to get this out for review even though many of the units tests don't pass yet. Its a bit rough at the moment but there was a couple of things that I wanted to talk about.

1. does it make sense to have ignoreElements where there is a toCompletable.
2. the same goes for single when there is a toSingle.
3. moved toFuture to Single since it seems to fit better.

[akarnokd]

Don't delete the old ops because we can macro fuse them back in such cases:
source.reduce(...).toFlowable()

[akarnokd]

I'll post a PR that incorporates some helper types and demoes what I mean by macro-fusion for these Flowable->X and Observable->X conversions.

[Mauin]

@abersnaze Your commit somehow has me as it's author.

[akarnokd]

@Mauin yeah it's odd

@abersnaze
See #4484 about how we could do this while keeping the performance when converting back to the Flowable/Observable.

Also it would be great if you didn't mix plain addition to Maybe with the other changes in one PR.

[abersnaze]

@Mauin something wires must have got crossed my last rebate. I'll. Try and fix it before it's merged.

@akarnokd would you like the additions as preliminary PR before this one?

[akarnokd]

Yes, that would be great.

[akarnokd]

Let me take out the Maybe additions into a separate PR.

[akarnokd]

does it make sense to have ignoreElements where there is a toCompletable
the same goes for single when there is a toSingle.

Reactor's Flux does return Mono<Void> for ignoreElements (last time I checked) and their community liked it. I think ignoreElements is more intuitive for naming the function. The question is, how the return type change will disrupt the developer's flow and how many time does he/she apply .toFlowable() (which we dutifully try to optimize) to get back to the Flowable/Observable world:

Flowable.range(1, 10)
.flatMap(v -> .saveToDb(restCall(v)).ignoreElements().toFlowable())
.blockingLast(0)

To avoid this burden, we have to provide flatMapCompletable(T -> Completable) etc in the Flowable/Observable as well, or for basically any XMap(Function) operator there is (concatMap, concatMapDelayError, flatMap, switchMap)

[akarnokd]

Closing as out of date and will be redone in subsequent PRs.