remote: accept a repo and name for renaming

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.

remote: accept a repository and remote name for deletion

We don't need the remote loaded, and the function extracted both of
these from the git_remote in order to do its work, so let's remote a
step and not ask for the loaded remote at all.

This fixes #2390.

With opportunistic ref updates, git has introduced the concept of having
base refspecs *and* refspecs that are active for a particular fetch.

Let's start by letting the user override the refspecs for download.

This option make it easy to ignore anything about the server we're
connecting to, which is bad security practice. This was necessary as we
didn't use to expose detailed information about the certificate, but now
that we do, we should get rid of this.

If the user wants to ignore everything, they can still provide a
callback which ignores all the information passed.

If the certificate validation fails (or always in the case of ssh),
let the user decide whether to allow the connection.

The data structure passed to the user is the native certificate
information from the underlying implementation, namely OpenSSL or
WinHTTP.