Rewrite concat operation to not block on subscribe

[Treora]

Hi,
While trying to stop the subscribe function from blocking, I ended up rewriting the most of the concat operation. From related issue discussions it appears the desired behaviour is still under debate, so I hope you agree on the chosen approach. See the explanation below.
Because practically it implements two asynchronous observers that interact with eachother, there are quite a few possible race conditions and other possibilities to break the Rx grammar, but I hope I fixed all of them.
Regards,

Gerben

The concat operator previously blocked on calling subscribe until all the
sequences had finished. In quite some cases this results in unwanted (and
unexpected) behaviour, such as when prefixing an infinite Observable
with a fixed one, for example when using startWith (which calls concat):
someInputStream.startWith(123).subscribe(x -> print(x));
This statement will block indefinitely if the input stream is infinite. Also
on finite sequences it seems silly to have to wait for them to finish.

In this new approach the incoming observables are put into a queue, instead
of waiting for the whole sequence to finish. When the first observable
completes, the next one is taken from the queue and subscribed to, and so
on. The queue can be extended while processing the observables, and
onCompleted is only called when both the source of observables has completed
and all observables in the queue have been read.

[cloudbees-pull-request-builder]

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

[benjchristensen]

That sounds like exactly what we want and discussed this morning at #270.

I don't have time to review right this minute but will do so this week as I'd like concat to be non-blocking for the 0.9 release.

Thank you!

[billyy]

Thanks for the fix. The code looks good and I have added new unit test to check for subscribe() returning before the Observable of Observable onComplete() is called.