The rfind challenge

[Phil Lavoie]

> The order of the range returned is the same as the one received.
Not true. It should default to the genuine bidirectional range's 
direction.
If it was reversed before calling rfind we could: let the user 
reverse the result again or add the possibility to query the 
range to know it it's already been reversed (compared to original 
ordering):

@property bool reversed() {}

In fact, this is to be known anyways if the range has to keep 
internal data to know in which direction it has to move. Meaning, 
reverse should be implemented like that:

VOID reverse() {
  _reversed = true;
}

instead of

ReversedBidirectionalRange reverse() {
   return blablabla...
}

There truly are multiple ways to implement a solution to this 
problem. We could also have merge decide the direction of the 
range based on the "end" range (since we are moving towards this 
one).