What's in git.git "next"

I've fixed up merge-recursive not to warn "working file will be
clobbered" when unneeded, and merged it to "next" tonight.  This
is a usability fix but if done incorrectly we can break a safety
valve.

The "next" version changes behaviour from the traditional one
when (1) paths that are untracked in our branch exists in the
common ancestor and the other branch we merge into our branch,
(2) the other branch did not make any changes to these paths,
and (3) the working tree has these paths as untracked files.

Under this condition, 3-way merge decides the path should not
exist in the result.  This has not been changed (and shouldn't
be).  But what is being fixed is what "should not exist" means.
We used to say "we have that path in our working tree, which
will be lost by the merge, so we won't merge".  Which was
perhaps safer but was inconvenient.  The corrected behaviour
should be "the path is not tracked in our branch, and the result
of the merge won't have it tracked either, and we will leave
those untracked working tree files as they were".

I added a handful tests to t6022 to catch potential breakages,
and the code still passes them, but that does not mean it is
perfect.  If the program refuses to proceed when it can, you
found a safer breakage I do not worry too much about.  If the
program overwrites or loses an untracked working tree file as a
result of the merge, then that means the updated merge-recursive
relaxed the check too much.

So please handle this with a bit of extra care than usual; I'd
appreciate extra sets of eyeballs to sanity check.