Already cherry-picked commits should not be re-included.  If all changes
included in a commit exist in the upstream, then we should error with
GIT_EAPPLIED.

Commit the current patch of a rebase process.

`git_rebase_next` will apply the next patch (or cherry-pick)
operation, leaving the results checked out in the index / working
directory so that consumers can resolve any conflicts, as appropriate.

Abort an in-progress rebase and move the working directory and
repository back to the ORIG_HEAD state.

Introduce `git_rebase` to set up a rebase session that can
then be continued.  Immediately, only merge-type rebase is
supported.

Clean up some warnings

config: remove the refresh function and backend field

remote: accept a repo and name for renaming

Fixed memory leak in git_tag_delete()

clar: use a custom temp directory name

[RFC] Use CommonCrypto for hashing

remote: delete git_remote_supported_url()

Remote objects are not meant to be changed from under the user. We did
this in rename, but only the name and left the refspecs, such that a
save would save the wrong refspecs (and a fetch and anything else would
use the wrong refspecs).

Instead, let's simply take a name and not change any loaded remote from
under the user.

This function does not in fact tell us anything, as almost anything with
a colon in it is a valid rsync-style SSH path; it can not tell us that
we do not support ftp or afp or similar as those are still valid SSH
paths and we do support that.

OSX has its own cryptographic library, let's make use of it instead of
calling out to OpenSSL.

We have been refreshing on read and write for a while now, so
git_config_refresh() is at best a no-op, and might just end up wasting
cycles.

Refresh git configuration before looking for the tracking branch redux.

ssl: dump the SSL ciphers in favour of TLS