Feature request: Implement DoubleEndedIterator for MergeBy if the source iterators implement DoubleEndedIterator

[frankdavid]

The current implementation of next() makes use of Peekable. Both iterators get peeked and a comparator is used to decide which element is picked / which iterator gets advanced.

The main difficulty when implementing next_back() for DoubleEndedIterator would be that Peekable only allows peeking the front and not the back. The MergeBy struct would either manually have to store the front and back peeked values or use a data structure like DoubleEndedPeekable.

If we could peek the back, the rest of the implementation would be straightforward, only the comparator's return value would need to be negated when iterating from the back.

[Philippe-Cholet]

There is some work of mine in #736 that would change the internal behavior from peekable to put_back but that does not change the fact it only looks at the front and not the back. I guess it would need some DoubleEndedPutBack (or store both fronts).

EDIT: I highly doubt it will be implemented, too many implications to the code for what seems to have little use case. What about it1.rev().merge_by(it2.rev(), func)?
I guess a DoubleEndedPeekable structure would be an intermediary feature.