MergeMap with Iterable and resultSelector overloads

[akarnokd]

Listed in #653.

[akarnokd]

Forgot an overload.

[cloudbees-pull-request-builder]

RxJava-pull-requests #650 SUCCESS
This pull request looks good

[cloudbees-pull-request-builder]

RxJava-pull-requests #651 SUCCESS
This pull request looks good

[zsxwing]

Looks it can be implemented by a simple class Pair, for example:

    public <U, R> Observable<R> mergeMap(final Func1<? super T, ? extends Observable<? extends U>> collectionSelector,
                       final Func2<? super T, ? super U, ? extends R> resultSelector) {
        return flatMap(new Func1<T, Observable<Pair<T, U>>>() {
            @Override
            public Observable<Pair<T, U>> call(final T t) {
                return collectionSelector.call(t).map(new Func1<U, Pair<T, U>>() {

                    @Override
                    public Pair<T, U> call(U u) {
                        return new Pair<T, U>(t, u);
                    }
                });
            }
        }).map(new Func1<Pair<T, U>, R>() {
            @Override
            public R call(Pair<T, U> pair) {
                return resultSelector.call(pair._1, pair._2);
            }
        });
   }

    private static class Pair<T1, T2> {
        T1 _1;
        T2 _2;
        Pair(T1 _1, T2 _2) {
            this._1 = _1;
            this._2 = _2;
        }
    }

[akarnokd]

I didn't want to introduce Pair for this.

[zsxwing]

You can use any better class to replace Pair. However, I think we do not need to reimplement flatMap again here.

[zsxwing]

Looks these operators can be implemented by composing the existing operators.

[benjchristensen]

I agree there is likely some simplification we can do on this, but I'm going to merge as the public APIs look correct and unit tests are good. We can iterate on the implementation internally.