Fixed race & late termination condition.

This is quite a complex operator with lots of cases.

Properties:
1) If there aren't any elements queued up and nothing is requested but terminal event received, emit terminal event and quit.
2) If there are elements in the queue and a terminal flag, and at least the same amount is requested, deliver the events and the terminal event.
3) If more was requested and more became available just after the loop and before the synchronized block, keep looping.
3.a) If more was requested but nothing is available or nothing was requested and something is available: quit and let either the onNext or request do the subsequent drain.
3.b) If elements and termination was produced but not requested: quit and let the request do the drain
3.c) If termination was requested and no elements produced: loop , emit terminal event and quit.

In table form:
```
Available | Terminated | Requested | Action | Reason
   yes         yes          yes       loop    can deliver available
   yes         yes          false     quit    can't deliver available
   yes         no           yes       loop    can deliver available
   yes         no           no        quit    can't deliver available
   no          yes          yes       loop    loop will deliver termination only and quit
   no          yes          no        loop    loop will deliver termination only and quit
   no          no           yes       quit    nothing to deliver
   no          no           no        quit    nothing to deliver
```
Reasoning through this it feels like it is safe that we will not have race conditions. For mental clarity I'm writing my thoughts here as this is non-trivial ...

- threadA is draining from n->0
- threadA takes the mutex on line 207
- threadB enters request and increments 0->1
- threadB hits the mutex on line 168 and waits
- threadA either sees the new value on line 209 and continues, or it skips the condition on line 221 and loops again ...
... OR threadA does not see the new value and returns.
- if threadA returns then threadB will unblock and start draining
- if threadA loops again, it will release the lock and threadB will be released but not start draining and do nothing

Thus either way we get the new value drained by either threadA or threadB. 

Am I reasoning through this correctly?