Diff rename detection cycle fixes

[arrbee]

As @ethomson has pointed out in #1656, diff rename detection has problems when you introduce a cycle of renames (a->b, b->c, c->a) because processing the earlier rename of a->b would alter the diff records so that when it was time process b->c, the b record was no longer the appropriate match.

Instead of making huge changes, this PR fixes this by tweaking a few details:

1. When looking for the closest match to a given record, if we displace an earlier located match, then note that we "bumped" a record and repeat the initial phase of finding closest matches until no records get bumped.
2. When updating records in place, always make the target record into the RENAME record (i.e. make this a true reverse mapping, even for data updates) so we always preserve records that are sources if possible.
3. If we are forced to overwrite a source record (which now only happens when we have two split MODIFIED records), update the best match mappings to point the unprocessed mapping at the new record location.

This PR includes @ethomson's previously failing tests from #1656 and contains my fixes for the issue. Hopefully he will look this over and give it his blessing.

[arrbee]

As an optimization, the loop that finds the best matches (which is rerun if a record is bumped) could be adjusted so that records which are not bumped after a run are marked as "finalized" and don't have to be reprocessed on later times through the loop. The code doesn't do that now. I'm not sure if it would actually be a win for the additional complexity.

[ethomson]

So much better than my fix would have been.