I spent an hour banging my head against this, when it was because the
remote didn't trust my key.

Use `git_sysdir_find_homedir_file` to identify the path to the home
directory's `.ssh/known_hosts`; this takes Windows paths into account by
preferring `HOME`, then falling back to `HOMEPATH` and `USERPROFILE`
directories.

transport: fix capabilities calculation

This looks like a typo to me, from what i can see these lines were
added at the same time and because of how capabilities are calculated,
it's likely that this code will work in situations where these
capabilities were the last ones.

The server and client negotiate a single hostkey, but the "best" cipher may not
be the one for which we have an entry in `known_hosts`. This can lead to us not
finding the key in known_hosts even though we should be connecting.

Instead here we look up the hostname with a nonsense key to perform a lookup in
the known hosts and set that. This is roughly what the OpenSSH client does as
well.

It turns out this has been available in libssh2 for a long time and we should
have been verifying this the whole time.

Httpclient internally stores a copy of the certificate_check callback and
payload. When connecting via HTTPS, and if the server sends back
"Connection: close" after the first request, the following request would
attempt to re-use the httpclient and call the (now outdated) callback. In
particular for pygit2 this is a problem, since callbacks / payloads are only
valid for the duration of a libgit2 call, leading to a ffi.from_handle()
error and crashing the Python interpreter.

The experimental function signature is only available when
`GIT_EXPERIMENTAL_SHA256` is enabled.