[BUG] show breakage of status for copy+conflict

[BUG] show breakage of status for copy+conflict

This is more intended to be a demonstration of a bug than an actual
test for inclusion into the library. It probably needs some cleaning
and moving around if it is to be included.

I noticed during a rebase that a conflicted file was not showing up
under the "both changed:" line, and was instead showing up as the
original name of a rename.
This was because the file had conflicts, and so was not in the index
(or at least, not in stage 0, if I have my terminology correct), while
another, very similar (both based on the same template) file had been
added as part of the same change on my side. This has several
interesting effects:
  - the file showed up as the original of a renamed file
  - the file did not show up under the list of files with staged changes
  - the file did not show up under the list of files with unstaged
    changes

Clearly, this is incorrect. It also had the side-effect of causing me to
accidentally add files with conflict-markers, as I thought that perhaps
the merge was simply confused about a similar file having been added.
That is, I thought the file had simple been removed from the index, so
I added it, conflict-markers and all.

the test presented here is based on conflict+copy, a simplification of
the real-world "conflict+addOfSimilarFile" scenario, as it demonstrates
the problem without the need to make up two similar-but-not-copied
files.

in testing, I noticed that "git status" shows the expected results for:
git checkout modify-and-copy && git merge modify-a-file

but shows the incorrect results for:
git checkout modify-a-file && git merge modify-and-copy

I don't really have the time right now to look for exactly what causes
this bug, so I'm hoping that posting a demonstration of it will get
someone else to fix it for me.