[RFH] Merge driver

[Junio C Hamano <junkio@cox.net>]

Some people may be alarmed and feel concerned that I already
have Daniel's and Fredrik's merge in the "master" branch; I feel
this deserves some clarification.

The change Daniel made is a natural enhancement of an existing
program.  It spent unusually long time in the proposed update
queue exactly because read-tree was so fundamental, and I wanted
to make sure there is no serious regression.  Most importantly,
the original merge mechanism, git-resolve, is not dropped, and
'git-pull' uses that, not 'git-merge', after fetching a remote
head.  So for everyday use, nothing has changed.

I did the 'git-merge' strategy backend mechanism because I
wanted to play it safe.  It makes it easy to give the set of
conservative strategies as default for every day use, while
allowing us to try more experimental strategies which can be
used only by an explicit user request.  Introduction of
additional merge strategies, such as the Fredrik merge or
rename-detect merge which is yet to be written, is in a sense
similar to adding new filesystems to the stable kernel tree --
as long as they stay optional and do not touch the core deeply,
they tend to be safer changes than other kinds, and we can add
them more or less anytime in the stable series without impacting
stability.

I intend to eventually update git-pull to use git-merge, and I
am hoping that I can do so before we hit 1.0, once we are sure
that 'git-merge -s stupid' behaves identically as 'git-resolve',
and 'git-merge -s resolve' fares no worse than 'git-resolve'.  I
personally feel I've done enough tests to ensure that already,
but help from the community is as always appreciated.