win32: update git for windows compatibility

Improve documentation

We look for a Git for Windows installation to use its git config,
so that clients built on libgit2 can interoperate with the Git for
Windows CLI (and clients that are built on top of _it_).

Look for `git` both in the `PATH` and in the registry.  Use the _first_
git install in the path, and the first git install in the registry.

Look in both the `etc` dir and the architecture-specific `etc` dirs
(`mingw64/etc` and `mingw32/etc`) beneath the installation root.

Prefer the git in the `PATH` to the git location in the registry so that
users can override that.

Include more tests for this behavior.

Provide a helper function to find an executable in the current process's
PATH.

With Git for Windows >= 2 the share folder is in an architecture specific subfolder.

This also add support for Git for Windows versions between 2 and 2.24 where also the etc folder is in an architecture specific subfolder.

Signed-off-by: Sven Strickroth <email@cs-ware.de>

Signed-off-by: Sven Strickroth <email@cs-ware.de>

Removal of the last 4 chars is only required for Git for Windows installations in order to find the "root" folder of the Git installation.

Fixes issue #5127.

Signed-off-by: Sven Strickroth <email@cs-ware.de>

Could happen if the path to git.exe is near to MAX_PATH and we append a longer subdir such as "share/git-core" to it.

Signed-off-by: Sven Strickroth <email@cs-ware.de>

Support scp style paths with ports

Fix typos

Instead of trying to figure out a repo's path from a URL by hand, parse
a URL using the parsing functionality.

We occasionally need to determine whether a given string is a URL or
something else.  (The "something else" may be a git path in a different
format, like scp formatting, which needs to be handled differently.)

Provide a mechanism for parsing scp-style paths (eg
`git@github.com:libgit2/libgit2` into the url form
`ssh://git@github.com/libgit2/libgit2`.)

GitHub is removing support for the unauthenticated git protocol; test
with the https protocol.

remote: support `http.followRedirects` (`false` and `initial`) and follow initial redirects by default

c99: change single bit flags to unsigned

Test that we honor `http.followRedirects` when set to initial or false.

Give callers the ability to select how to handle redirects - either
supporting redirects during the initial connection (so that, for
example, `git.example.com/repo` can redirect to `github.com/example/repo`)
or all/no redirects.  This is for compatibility with git.

In redirect application logic, (optionally) allow off-site redirects.

We (thankfully) don't have flaky tests anymore, don't retry them.

The new version of our test git server adds redirect support.  Upgrade
to it.

The existing mechanism for providing options to remote fetch/push calls,
and subsequently to transports, is unsatisfactory.  It requires an
options structure to avoid breaking the API and callback signatures.

1. Introduce `git_remote_connect_options` to satisfy those needs.

2. Add a new remote connection API, `git_remote_connect_ext` that will
   take this new options structure.  Existing `git_remote_connect` calls
   will proxy to that.  `git_remote_fetch` and `git_remote_push` will
   proxy their fetch/push options to that as well.

3. Define the interaction between `git_remote_connect` and fetch/push.
   Connect _may_ be called before fetch/push, but _need not_ be.  The
   semantics of which options would be used for these operations was
   not specified if you specify options for both connect _and_ fetch.
   Now these are defined that the fetch or push options will be used
   _if_ they were specified.  Otherwise, the connect options will be
   used if they were specified.  Otherwise, the library's defaults will
   be used.

4. Update the transports to understand `git_remote_connect_options`.
   This is a breaking change to the systems API.