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.