When the latest generation of the move detection code was written, it
was able to properly determine the beginning of move ranges when
adjacent to other move ranges coming from different lines. For instance,
if 5 lines were moved, but the first 2 were reorderd to be placed after
the last 3, the move detection code would notice this and show this as
two separate move range.

Somewhere along the line, this regressed, and the move detection code
was seeing this as one single move. That's a bit misleading, since while
the code has moved, the order did not remain the same.

This change fixes this by improving the logic for determining the
beginning of a move range, and adding unit tests to ensure it works as
expected.

Unit tests pass.
Tested manually with a review request I have that moves a few lines and

swaps the order of the moved lines.