This does two things.

 - When one branch renamed and the other branch did not, the
   resulting half-merged file in the working tree used to swap
   branches around and showed as if renaming side was "ours".
   This was confusing and inconsistent (even though the conflict
   markers were marked with branch names, it was not a good
   enough excuse).  This changes the order of arguments to
   mergeFile in such a case to make sure we always see "our"
   change between <<< and ===, and "their" change between ===
   and >>>.

 - When both branches renamed to the same path, and when one
   branch renamed and the other branch did not, we attempt
   mergeFile.  When this automerge conflicted, we used to
   collapse the index.  Now we use update-index --index-info
   to inject higher stage entries to leave the index in unmerged
   state for these two cases.

What this still does _not_ do is to inject unmerged state into
the index when the structural changes conflict.  I have not
thought things through what to do in each case yet, but the
cases this commit cover are the most common ones, so this would
be a good start.
Signed-off-by: NJunio C Hamano <junkio@cox.net>