read-cache: save index SHA-1 after reading

This can be used for verification later..
read-cache: new extension for split-index mode

Normally all index info is in $GIT_DIR/index. This split-index mode
introduces $GIT_DIR/index.2nd. The intent is $GIT_DIR/index is large
and not often updated, while index.2nd is smaller and updated
often.

This mode only makes sense for _large_ index where a write could take
a few hundred miliseconds to complete. Read operations still suffer
because of the size of the main index. But because the main index
rarely changes, we could cache its content in a daemon so we don't
have to verify its SHA-1 on every read.

A new extension "link" is introduced which contains an SHA-1. The
rules for split-index mode are

 - If "link" extension is present in $GIT_DIR/index, we're in
   split-index mode and $GIT_DIR/index.2nd must be read if
   present. This is non-optional extension, which means all current
   git implementations will refuse to read this index.

 - index.2nd must contain "link" extension, which contains the
   trailing SHA-1 of $GIT_DIR/index. If this SHA-1 does not match the
   main index trailing SHA-1, index.2nd is considered obsolete and
   ignored.

 - The second index can only contain extensions (i.e. cache_nr of
   index.2nd must always be zero). Both optional and non-optional
   extensions are allowed.

 - If the same extension appears in both indexes, the second index
   version is preferred.

 - $GIT_DIR/index.lock is always held no matter which index is updated

 - Both indexes must not be updated in the same lock (i.e. you need
   lock twice for updating both of them)

 - If the main index is updated, it must absorb all contents of the
   second index to itself (because after the update, the main index
   SHA-1 will change, invalidating second index)

 - The second index must also be locked if it's updated. So there will
   be index.lock _and_ index.2nd.lock when the second index is
   updated. After index.2nd is committed, index.lock could be rolled
   back.

Note that $GIT_DIR/index.2nd does not play nice with prepare_index()
in builtin/commit.c. write_locked_index() forces always updating
$GIT_DIR/index in this case. Maybe in future we could introduce
GIT_INDEX_2ND_FILE to support this case.
update-index: new options to enable/disable split index
read-cache: new extension "CEUP" for fast refresh and file update

When this extension is enabled and you refresh the index, or update
SHA-1 of an entry in index (but not add or delete), the changes will
be written in $GIT_DIR/index.2nd, leaving the main (potentially large)
$GIT_DIR/index untouched. This extension is automatically enabled when
split-index is used.

This extension consists of two parts: the first parts store most often
updated fields in stat data, designed to make sure refresh operation
does not impact the main index. The second part stores updated SHA-1
for "git add -u" and friends.
read-cache: move cache-tree extension to index.2nd

Updating an entry will invalidate some path in cache-tree, which
triggers $GIT_DIR/index update. Move cache-tree to index.2nd so that
the changes are contained within index.2nd