RFC: optionally reject case-clone branch names

[David Turner <dturner@twopensource.com>]

At present, it is possible to have two branches which are the same but
for case.  This works great on the case-sensitive filesystems, but not
so well on case-insensitive filesystems.  It is fairly typical to have
case-insensitive clients (Macs, say) with a case-sensitive server
(GNU/Linux).  

Should you attempt to pull on a Mac when you have case-clone branches
with differing contents, you'll get an error message containing
something like "Ref refs/remotes/origin/lower is at
[sha-of-lowercase-branch] but expected [sha-of-uppercase-branch]....
(unable to update local ref)"

Fortunately, nobody uses Macs for git servers, because on a Mac server,
if you push a branch called capital-M Master (that differs from
lowercase-m-master), nobody else can push to (lowercase-m) master until
the branch is removed.  Once the branch has been removed, it can no
longer be recreated.

I think a git client that used only packed-refs would not have any
problems with case-sensitivity of branch names, but I assume that there
are good reasons this hasn't yet been done.  At any rate, there are
plenty of older clients out there.

RFC follows:

1. On a case-insensitive server, git receive-pack ought to always reject
branches which are same-but-for-case of existing branches.
2. On a case-sensitive server, the same rule by default, with an option
to allow the old behavior.

Let me know if, should I write these patches, they would be likely to be
accepted.