This adds two new object types to git-annex, GITMANIFEST and a GITBUNDLE.

GITMANIFEST--$UUID is the manifest for a git repository stored in the
git-annex repository with that UUID.

GITBUNDLE--sha256 is a git bundle.

# format of the manifest file

An ordered list of bundle keys, one per line.

The last bundle in the list provides all refs that are currently stored in
the repository. The bundles before it in the list can incrementally provide
objects, but not refs.

# fetching

1. download GITMANIFEST for the uuid of the special remote
2. download each listed GITBUNDLE object that we don't have
3. `git bundle unpack` each bundle in order
4. `git fetch` from the last bundle listed in the manifest

# pushing (incrementally)

1. create git bundle all refs that will be stored in the repository, 
   and objects since the previously pushed refs
2. hash to calculate GITBUNDLE key
3. upload GITBUNDLE object
4. download current manifest
5. append GITBUNDLE key to manifest

# pushing (replacing incrementals with single bundle)

1. create git bundle containing all refs stored in the repository, and all
   objects
2. hash to calculate GITBUNDLE object name
3. upload GITBUNDLE object
4. download old manifest
4. upload new manifest listing only the single new GITBUNDLE
5. delete all other GITBUNDLEs that were listed in the old manifest

# multiple GITMANIFEST files

Usually there will only be one per special remote, but it's possible for
multiple special remotes to point to the same object storage, and if so
multiple GITMANIFEST objects can be stored.

It follows that the UUID of the special remote has to be included in the
annex:// uri, to know which GITMANIFEST to use when cloning from it.