[Replay] implement with a bounded buffer strategy (v1.1)

[twittemb]

The idea behind this operator is to keep track of the latest elements produced by an async sequence and replay them every time a new iterator is created. To avoid uncontrolled memory footprint, the history is bounded.

For instance with a replay count of 2:

a first iterator iterates 3 times over a base:
- base produces 'a': 'a'  is stacked in the history ['a'] and the iteration receives 'a'
- base produces 'b': 'b'  is stacked in the history ['a', 'b'] and the iteration receives 'b'
- base produces 'c': 'a' is removed from the history and 'c'  is stacked in the history ['b', 'c'] and the iteration receives 'c'

a second iterator iterates 3 times over the base:
- the history is replayed with ['b', 'c'], the iteration receives 'b' and 'c'
- the base produces 'd': 'b' is removed from the history and 'd'  is stacked in the history ['c', 'd'] and the iteration receives 'd'

This kind of operator could be useful applied after a broadcast (#242) operator. It would allow to replay the elements that were produced while all iterators were not yet iterating.

[FranzBusch]

I don't think we can do it like this. The problem here is that if the upstream AsyncSequence is unicast then this will can potentially crash or not work.

In general, I think we need to approach the implementation a bit differently since the replay algorithm is basically a multicast algorithm. So it shares some of the same implementation characteristics as broadcast does. Specifically, I think we need to only ever create one upstream iterator. That should be done on the first call to next to any of the replay iterators. Furthermore, we need to make sure that we only issue a single next call to the upstream even if we have multiple downstreams.

Before going ahead and implementing this further, I would recommend to wait how the broadcast algorithm evolves and once we have that we should revisit replay. Let me know what you think!