The new interdiff file matching had a couple of cases where files
weren't matching up, or matching up well enough. It was possible to get
into states where the same file would appear twice, once with the
changes reverted (from the first revision) and once with the changes
added (from the second revision). Depending on new/deleted states, this
could actually happen even if the file wasn't actually changed between
revisions.

The changes have a lot to do with the fact that the "new" file state
isn't always very reliable. We sometimes set things as new when the file
was introduced in a parent diff (a bug that we need to fix separately).

This change improves the logic, catching two more cases. First, after
the full-detail check (same source/destination files and new/delete
states), we now check for matches where the source/destination match
between the two, but where the source and destination themselves do not
match (moved/copied files). These take precedence over files with
new/deleted state changes (as per the bug above).

After all the other matching checks, we now do one last check to match
any remaining files together that share the same source files. This
falls back to the original behavior we had for interdiff matching, with
one exception: Files that are flagged as new in revision 2 but not in
revision 1 will not match, and files flagged as deleted in revision 1
but not 2 will not match.

This should address the major remaining issues for interdiff matching.

Unit tests pass.
Tested with a real-world diff that had problems on reviews.reviewboard.org.

There were two entries before, but now they match up correctly.