A customer hit a situation where diff revision 1 was not matching files
from revision 2, despite the file paths and content all being the same.
It turned out that this was due to the files in revision 1 appearing as
modified while the files in revision 2 were shown as new, despite the
actual diff for revision one clearly showing the files should have also
been new. The culprit turned out to be the parent diffs, which were
showing the files as being deleted, resulting in the main diffs
re-introducing those files, and the whole thing being parsed with source
revision information from the parent diff (for repository lookup
purposes).

The interdiff filename matching intentionally does not match files when
they're modified in revision 1 but re-introduced in revision 2, with the
idea being that if this case was hit, it means the files originally
modified in revision 1 were deleted upstream, and revision 2 is
re-introducing them (possibly with very different content). While we may
want to revisit that later, this change simply adds another condition to
support files that were modified in revision 1 and re-added in revision
2 when the resulting revisions are equal between the two. This is a
clear sign that we're actually dealing with the same file, and should
ignore the "new" states.

Unit tests have been updated to inject resulting revisions, and to check
the new case versus the old one.

Tested the algorithm change against the customer's diff, and verified

that the result was correct and more easily reviewable.
All unit tests pass.