ssh: backport windows known_hosts fixes to v1.4

We provide `BUILD_PATH` to our build script; provide it and mutate
`PATH` when running our tests as well.

We were previously using `cygpath` to try to convert a _list_ of Windows
paths into cygwin / Unix style `PATH` format. This does not work -- it
treats the path list as a single path (with semicolons -- understandably
as those are allowed characters in a Windows path).

For example, `C:\One;C:\Two;C:\Three` is converted to
`/c/one;c:/two;c:/three`.

Add a new function to convert path lists, so that paths are split by
semicolon and fed to `cygpath` independently, then re-joined with a
colon. This means that our example `C:\One;C:\Two;C:\Three` is correctly
converted to `/c/one:/c/two:/c/three`.

We provide `BUILD_PATH` to our build script; provide it and mutate
`PATH` when running our tests as well.

Teach the clone tests how to clone from github.com, when given a keypair
with a passphrase and known_hosts data. This allows us to better
exercise our known_hosts checking and ensure that the lifecycle of the
certificate callback matches our expectations.

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.

Provide a mechanism to look up the user's home directory, using the same
mechanism that we use for locating the global configuration path (a
fancy name for saying "the home directory").

SSH known hosts lookups now use this, instead of simply looking at the
HOME environment variable, to support Windows-style home directory
lookups in `HOME`, `HOMEPATH`, or `USERPROFILE`.

ssh: perform host key checking by default

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.

We're currently running it as part of the online suite but that doesn't have any
setup for ssh so we won't find the GitHub keys we set up during the test.

It doesn't need the private key setup as we just want to make sure we see some
auth request from the server, but with the addition of hostkey checking we're
now seeing it fail when we skip these tests.

Currently just the one test needs it.

The ssh-rsa makes sure we're asking for the cipher we find in `known_hosts` as
that won't be the one selected by default. This will be relevant in later changes.

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

slide_hash knowingly reads (possibly) uninitialised memory, see comment
lower down about prev[n] potentially being garbage. In this case, the
result is never used - so we don't care about MSAN complaining about
this read.

By adding the no_sanitize("memory") attribute, clients of zlib won't
see this (unnecessary) error when building and running with
MemorySanitizer. An alternative approach is for clients to build zlib
with -fsanitize-ignorelist=... where the ignorelist contains something
like 'fun:slide_hash'. But that's more work and needs to be redone
for any and all CI systems running a given project with MSAN. Adding
this annotation to zlib's sources is overall more convenient - but
also won't affect non-MSAN builds.

This specific issue was found while running git's test suite, but has
also been reported by other clients, see e.g. #518.

The `crc32_combine_gen64` missed a prototype in our define path.
Add one.

In the ownership checks implemented for CVE-2022-24765, we disallowed
users to access their own repositories when running with `sudo`.

Examine the `SUDO_UID` environment variable and allow users running
with `sudo`. This matches git's behavior.

To match git's behavior with CVE 2022-29187, validate not only the
working directory, but also the gitdir and gitlink (if it exists). This
a follow up to CVE-2022-24765 that was fixed earlier.

Allow users in the administrator group to use git configs that are owned
by administrators.

Allow the user ownership to match if the file is owned by the admin
group and the user is in the admin group, even if the current process is
not running as administrator directly.

Refactor the file ownership checks so that callers can provide discrete
information about the ownership expectations to a single function.

The file ownership concepts can reflect the actual file ownership, they
are not necessarily limited to mocking the interface. Rename them so
that they can be more broadly applicable.

Ensure that we test opening a bare repository with odd permissions.

Update the new URL for mbedTLS.

Originally introduced in: 776a6a8e

This test case has recently been fixed in bdab2238, but that fix will only last for a year. Next year the same problem will crop up and the test will need to be re-edited.

This is not ideal as
- This test case becomes an unnecessary burden for developers
- Downstream distros or even just users who want to build older versions of libgit2 are guaranteed to have this test fail

Furthermore, this test case is entirely unnecessary, as the functionality that was originally (see 776a6a8e) intended to be tested is well-covered by subsequent tests which specify a date instead of a "x ago" specification.

Bug #6272 - fix crash in git_describe_commit.

Co-authored-by: Edward Thomson <ethomson@github.com>

When the passed object fails to be peeled into a commit pointer,
the cleanup code still tries to free the (uninitialized) pointer.

v1.4.3 release