When generating an interdiff that swaps a line below another, the

algorithm would generally opt to move the first line below the second,

representing the second as an "equals" line. The problem is, this second

line could have been newly-added in the original revision, but due to

the way the interdiff is generated, the equals line's range would not

overlap the original's range.
This change updates the algorithm to consider these cases. Now, if an

equal op is found, it backtracks, looking to see if a filtered-equal

precedes it. This will be enough to trigger combining the new range with

the filtered range into one big range and putting the filtered op and

current op back in the list of pending opcodes. This will cause the full

extent of the range to be reconsidered for any overlaps.
The result of this should be that line swaps should be represented

correctly in interdiffs, with minimal upstream line leaks (though there

may be some in practice).
Further improvements on this would involve peeking ahead to determine if

there's an insert/replace following the equal, which would be more

likely to be this situation. That would require a bit more work to how

we process and re-queue opcodes (we'd need to be able to consume the

next opcode and then put it back in a buffer that's lower precedence

than pending_opcodes).

Unit tests passed, covering all our provided sample datasets.
Manually tested with some customer-provided datasets, verifying

they were fixed.