Document that we no longer erroneously include credentials in the
FETCH_HEAD file.

If fetching from an anonymous remote via its URL, then the URL gets
written into the FETCH_HEAD reference. This is mainly done to give
valuable context to some commands, like for example git-merge(1), which
will put the URL into the generated MERGE_MSG. As a result, what gets
written into FETCH_HEAD may become public in some cases. This is
especially important considering that URLs may contain credentials, e.g.
when cloning 'https://foo:bar@example.com/repo' we persist the complete
URL into FETCH_HEAD and put it without any kind of sanitization into the
MERGE_MSG. This is obviously bad, as your login data has now just leaked
as soon as you do git-push(1).

When writing the URL into FETCH_HEAD, upstream git does strip
credentials first. Let's do the same by trying to parse the remote URL
as a "real" URL, removing any credentials and then re-formatting the
URL. In case this fails, e.g. when it's a file path or not a valid URL,
we just fall back to using the URL as-is without any sanitization. Add
tests to verify our behaviour.

Release v0.28.5

The v0.28 branch still uses an old SOVERSION style which includes the
minor version, only. Adjust the release script to reflect that.

The current release process is not documented in any way. As a result,
it's not obvious how releases should be done at all, like e.g. which
locations need adjusting.

To fix this, let's introduce a new script that shall from now on be used
to do all releases. As input it gets the tree that shall be released,
the repository in which to do the release, credentials to
authenticate against GitHub and the new version. E.g. executing the
following will create a new release v0.32:

    $ ./script/release.py 0.32.0 --user pks-t --password ****

While the password may currently be your usual GitLab password, it's
recommended to use a personal access token intead.

The script will then perform the following steps:

    1. Verify that "include/git2/version.h" matches the new version.

    2. Verify that "docs/changelog.md" has a section for that new
       version.

    3. Extract the changelog entries for the current release from
       "docs/changelog.md".

    4. Generate two archives in "tar.gz" and "zip" format via "git
       archive" from the tree passed by the user. If no tree was passed,
       we will use "HEAD".

    5. Create the GitHub release using the extracted changelog entries
       as well as tag and name information derived from the version
       passed by the used.

    6. Upload both code archives to that release.

This should cover all steps required for a new release and thus ensures
that nothing is missing that shouldn't be.

We currently unconditionally override the PATH variable with a custom
path with the main intent of making available our own custom MinGW
installation. This worked quite well so far, but is heavily dependent on
the machine we're running this on. And naturally, it fails on the new
Windows machines we need to upgrade to, as tools like CMake are not
contained in the path we currently set up.

Fix this by remodeling the way we set up the PATH environment. Instead
of overriding it completely, we now override it only when executing
the CMake build.

This is a subset of commit 95f329b49 (azure: upgrade to newer hosted VM
images, 2020-03-10), upgrading all of our Windows jobs to use
'vs2017-win2016' machines and macOS to 'macos-10.14'. This is intended
to keep our continuous integration builds from failing in the future, as
these images will get deprecated on March 31st. As this is in
preparation of a stable release, we do not want to upgrade any of the
other machines like is done in the mentioned commit but keep the impact
minimal.

fixup! azure: upgrade to newer Windows VM images

While the `git_refdb_backend()` struct has a version, we do not
initialize it correctly when calling `git_refdb_backend_fs()`. Fix this
by adding the call to `git_refdb_init_backend()`.