link.c, link.h: introduce fifth object type

Submodules suffer from one major design flaw: they are represented as
commit objects in the tree.  There are several problems with this:

1. Since the object is actually part of the submodule's object
   store (you can't even cat-file the commit), the superproject knows
   very little about the submodule.  We currently work around this by
   having an ugly .gitmodules file in the toplevel directory mapping
   upstream URLs to submodule paths.

2. We are restricted to having a concrete SHA-1 to convey what the
   subproject's HEAD should point to.  As a result, it is impossible
   to have true floating submodules.

3. It is impossible to initialize a nested submodule without
   initializing the containing submodule first.  This is a consequence
   of our .gitmodules hack, and we should really fix it.

4. Always stat'ing all subproject worktrees can be problematic if
   there are very large subprojects; we should be able to turn it off
   for some submodules selectively.  A good future direction would be
   to add more submodule-specific properties, instead of assuming that
   all submodules are equal.  Stuffing more properties into
   .gitmodules is really not a solution.

5. Finally, the git-submodule shell script has lots of horrible warts
   (like cd-to-toplevel for any operation) that are non-trivial to
   fix, and introduces a very unnatural layer of abstraction.

There are various specialized tools like mr, repo, gitslave, and
git-subtree, which offer different compositions solving some problems
while introducing limitations of their own.

We propose to fix the problem for good.  More specifically, introduce
a new object type corresponding to mode 16000 (gitlink).  This new
object will convey all the required information about the individual
submodules to the superproject.  Rework git core to get rid of
.gitmodules and git-submodule altogether.

This patch doesn't do anything by itself: although it is possible to
create link objects using 'git hash-object -t link',
parse_link_buffer() is unimplemented.  In future patches, we intend to
flesh out how core git will handle this object.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
sha1_file, link: write link objects to the database

On a 'git add', instead of returning the SHA-1 of the subproject
commit, write a real link object to the object database.  Also
implement parse_link_buffer() correspondingly.

index_path() determines the upstream_url and checkout_rev from a
pre-cloned submodule.  The checkout_rev is set to the SHA-1 of the
HEAD, and we get a non-floating submodule.

While at it, fix the 'ls-tree' output to correctly show a link object.
teach ce_compare_gitlink() about OBJ_LINK

This simply requires parsing out the checkout_rev from the link
object, and comparing its SHA-1 with that of HEAD.
builtin/log: teach show about OBJ_LINK

'git show' now works with link objects.
clone: introduce clone.submodulegitdir

This configuration variable comes into effect when 'git clone' is
invoked in an existing git repository.  Instead of cloning the
repository as-is, it relocates the gitdir of the repository to the
path specified by this variable.  Arguably, it does the right thing
when working with submodules.
sha1_file: write ref_name to link object

Great.  Now, we just have to write refs/modules/<branch>/* at
commit-time.
builtin/cat-link: implement new builtin

This is a simple program that calls unpack_trees() with a custom
callback that just prints the contents of whatever objects were
matched using revs.prune_data.  Blobs can be cat'ed directly from the
filesystem, so this program is primarily useful for links; git
cat-link <link> shows it up like a blob.

We will use this program to build edit-link.
builtin/edit-link: implement equivalent of editing blob

git edit-link <link> is exactly equivalent to editing a blob on the
filesystem.  We open up a buffer, giving the user a chance to edit the
link, and then.