An alternative for 'clone' with options

There's no need for this to be a pointer to somewhere else.

Hopefully clear up what they're for.

Make the difference more explicit.

This wasremoved as part of the large culling a few commits ago.

This is a small thing that by itself doesn't quite justify making the
user use clone_into.

The removal of many options which lead to the direct usage of the
user's checkout options means we should make sure they remain const.

This used to be done via transport flags, which was removed in a
previous commit.

The basic clone function is there to make it easy to create a "normal"
clone. Remove a bunch of options that are about changing the remote's
configuration.

Unify the code bases.

Downloading all tags is part of what makes it a clone instead of
simply a fetch.

This allows you to set up the repository and remote as you which to
have them before performing the clone operation.

Move this one as well, letting us have a single way of setting the
callbacks for the remote, and removing fields from the clone options.

The text progress and update_tips callbacks are already part of the
struct, which was meant to unify the callback setup, but the download
one was left out.

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.