stablerange: small style fix

merge-slicing: introduce and use "inheritance point" for merge The first part of the stable sorted list of revision of a merge will shared with the one of others. This means we can reuse subranges computed from that point to compute some of the subranges from the merge. That point is latest point in the stable sorted list where the depth of the revisions match its index (that means all revision earlier in the stable sorted list are its ancestors, no dangling unrelated branches exists). This is a bit expensive to find since we have to walk all the revision, but being able to reuse subranges in all case (not just regular changesets) provide a massive speedup so the cost is worth it.

stablerange: rearrange the code picking subrange to warm Same logic, as the previous changesets, we prepare the code before adding merge support.

stablerange: rearrange the reusing logic to prepare to merge We'll soon be able to reuse some lower range when dealing with merge too. So we prepare the code for this in advance for clarity.

merge-slicing: explain an alternative implementation in a comments It has a better time complexity so a C implementation would likely out perform the current implementation

merge-slicing: use reachable roots to filter the various branches Reachable roots does what we want and have a quite fast C implementation.

merge-slicing: simplify various aspect of the code Especially the case were the bottom have single heads is not more efficiently handled.

stablerange: soon it will not provide any benefit and it gets in the way This was a bit strange and memory consuming anyway.

revsfromrange: reuse information from the stablesort We collaborate with the stablesort to store the order that led to a merge. That way, when we needs to retrieve revision from that merge we can reuse that order. We might need to filter to only retains ancestors of the merge we care about but skipping the stablesort safe a large amount of time.

stablesort: allow a callback to be triggered on merge Storing some information as we sort is going to be useful to avoid performing multiple sort while computing the stablerange.

minor simplification around rangelength

more explicite name in revsfromrange

stablerange: cache parents We happens to be doing and awful amount of parent call. We cache them locally for efficiency.

merge-slicing: avoid doing the same work twice We have already computed the list of revision in that bottom slice as 'hrevs' so we do not need to compute it a second time.

stablerange: fix a bug when a top slice ended on a merge Our "smart" detection of merge was buggy if the top slice ended on a merge. This is not fixed and tested.