Having the setting be different from calling its actions was not a great
idea and made for the sake of the wrong convenience.

Instead of that, accept either fetch options, push options or the
callbacks when dealing with the remote. The fetch options are currently
only the callbacks, but more options will be moved from setters and
getters on the remote to the options.

This does mean passing the same struct along the different functions but
the typical use-case will only call git_remote_fetch() or
git_remote_push() and so won't notice much difference.

The signature for the reflog is not something which changes
dynamically. Almost all uses will be NULL, since we want for the
repository's default identity to be used, making it noise.

In order to allow for changing the identity, we instead provide
git_repository_set_ident() and git_repository_ident() which allow a user
to override the choice of signature.

This makes them show up in the reference, even if the text itself isn't
the most descriptive.

These have been found with

    grep -Przon '\n\ntypedef struct.*?\{' -- include
    grep -Przon '\n\ntypedef enum.*?\{' -- include

As git_clone now has callbacks to configure the details of the
repository and remote, remove the lower-level functions from the public
API, as they lack some of the logic from git_clone proper.

Analogously to the remote creation callback, provide a way for the user
of git_clone() to create the repository with whichever options they
desire via callback.

git_remote_set_transport now takes a transport factory rather than a transport
git_clone_options now allows the caller to specify a remote creation callback

Add docs for git_clone_local_t and move the docs for the
git_clone_options to each field.

If requested, git_clone_local_into() will try to link the object files
instead of copying them.

This only works on non-Windows (since it doesn't have this) when both
are on the same filesystem (which are unix semantics).