The user is unable to derive the number of deltas in the pack, as that
would require them to capture the stats exactly in the moment between
download and final processing, which is abstracted away in the fetch.

Capture these numbers for the user and expose them in the progress
struct. The clone and fetch examples now also present this information
to the user.

Show how many local objects were used to fix the thin pack in our fetch
example.

Don't increase the number of total objects, as it can produce
suprising progress output. The only addition compared to pre-thin is
the addition of local_objects to allow an output similar to git's
"completed with %d local objects".

There may be multiple deltas referencing the same base as well as OFS
deltas which rely on a thin delta. Deal with both at the same time by
injecting a single object and going back up to the main
delta-resolving loop.

When given an ODB from which to read objects, the indexer will attempt
to inject the missing bases at the end of the pack and update the
header and trailer to reflect the new contents.

Though unusual, a packfile may contain a delta whose base is a delta
that comes later. In order index such a packfile, we must not give up
on the first failure to resolve a delta, but keep it around.

If there is a pass which makes no progress, this indicates that the
packfile is broken, so fail accordingly.

Add git_transport_register, git_transport_unregister

Config subsection name should allow to have ']' and '\\' should allow to escape any characters

Redir refactor

Initial Implementation of progress reports during push

Never consider submodules for stashing

...before the helper's cleanup method tries to delete their files.

Fix x86/x64 size_t related warnings

This adds the basics of progress reporting during push. While progress
for all aspects of a push operation are not reported with this change,
it lays the foundation to add these later. Push progress reporting
can be improved in the future - and consumers of the API should
just get more accurate information at that point.

The main areas where this is lacking are:

1) packbuilding progress: does not report progress during deltafication,
   as this involves coordinating progress from multiple threads.

2) network progress: reports progress as objects and bytes are going
   to be written to the subtransport (instead of as client gets
   confirmation that they have been received by the server) and leaves
   out some of the bytes that are transfered as part of the push protocol.
   Basically, this reports the pack bytes that are written to the
   subtransport. It does not report the bytes sent on the wire that
   are received by the server. This should be a good estimate of
   progress (and an improvement over no progress).

Remove leading newlines from commit message

Fix libgit2/libgit2sharp#522

Add refdb.h to git2.h, reorder git2.h sanely

...and have that call manage replaced memory in the output structure.

Win32: handle http->https redirects

Bring error handling docs up to date