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.

It does the same as git_remote_supported_url() but has a name which
implies we'd check the URL for correctness while we're simply looking at
the scheme and looking it up in our lists.

While here, fix up the tests so we check all the combination of what's
supported.

 * Move the transport registration mechanisms into a new header under
   'sys/' because this is advanced stuff.
 * Remove the 'priority' argument from the registration as it adds
   unnecessary complexity.  (Since transports cannot decline to operate,
   only the highest priority transport is ever executed.)  Users who
   require per-priority transports can implement that in their custom
   transport themselves.
 * Simplify registration further by taking a scheme (eg "http") instead
   of a prefix (eg "http://").

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

This was a bad idea. Don't free except in the free function.

There is no reason why we need to use a callback here. A string array
fits better with the usage, as this is not an event and we don't need
anything from the user.

If the remote supports the symref protocol extension, then we return
that, otherwise we guess with git's rules.