This function returns true if the string starts with a `-` as that could be used
to inject options into commands we execute.

We now have no "big single object" that contains thread state.

Now that thread-local error data is handled in error, move the thread
local data out of the `threadstate` object, since it has now become
useless indirection.

Instead of having a separate type for saving state, we can re-use the
`git_error` structure. In practice, saving the error code along with the
`git_error` information has not proven necessary or useful, so it can be
removed to simplify down to re-using a single structure.

Most callers only need to _get_ error messages. Only callers implemented
more complicated functions (like a custom ODB for example) need to set
them.

(Callback users should likely ferry their own error information in their
callback payload.)

Callers want to be able to simply call `git_error_last()->message`,
not have to worry about whether `git_error_last()` returns NULL or not.

The error handling in the ssh certificate callback is straightforward.
There's no error messages from an external library that need to be
saved, we populate the error message ourselves. Since there's nothing
custom here, it does not need to use the error saving mechanism.

Add OpenSSH support

Handle custom paths for OpenSSH.

This helped when troubleshooting issues running the `ci/test.sh` script
locally.

Callers can specify the ssh command to invoke using `core.sshcommand` or
the `GIT_SSH` environment variable. This is useful for specifying
alternate configuration, and is particularly useful for our testing
environment.

Provide both cmdline-style handling (passing it to the shell on POSIX,
or directly to CreateProcess on win32) and execv style (passing it
directly to execv on POSIX, and mangling it into a single command-line
on win32).

Don't capture stderr, optimize for the CLI case.

Provide more user-friendly error messages in smart protocol negotiation
failures.

Provide a mechanism for callers to read from stderr.

Suppress SIGPIPEs during writes to our piped process. On single-threaded
applications, this is as simple as ignoring the signal. But since this
is process-wide, on multi-threaded applications, we need to use some
cumbersome `pthread_sigmask` manipulation.

Thanks to https://www.doof.me.uk/2020/09/23/sigpipe-and-how-to-ignore-it/
and http://www.microhowto.info:80/howto/ignore_sigpipe_without_affecting_other_threads_in_a_process.html

Instead of "early EOF", provide information on _when_ we're seeing the
EOF for debugging.

A transport may want to validate that it's in a sane state; when
flushing on close, don't assume that we're doing an upload-pack; send
the correct direction.

Now that we (may) exec a child process to do ssh, we don't want valgrind
reporting on that. Suppress children in valgrind runs.

There are no custom callbacks for OpenSSH; don't test them.

We can't reliably detect SIGPIPE on close because of platform
differences. Track `pid` and send `SIGTERM` to a function and ensure
that we can detect it.

We can now use the `git_process` class to invoke OpenSSH and use it as
an SSH transport. This may be preferred over libssh2 for a variety of
callers.

We may want to support SSH but with a different provider that is not
libssh2. Add GIT_SSH to indicate that we have some inbuilt SSH support
and GIT_SSH_LIBSSH2 to indicate that support is via libssh2. This is
similar to how we support GIT_HTTPS and GIT_OPENSSL, for example.

ci: update to macOS 12

ci: retry flaky online tests

cmake: fix openssl build on win32

since f15c8ac7 libgit unconditionally depends on secur32 on Windows
but only added it in cmake for the winhttp and schannel variants.
In case libgit is built against openssl it would fail to link.

This moves secur32 out of the https backend selection code into
the global win32 condition (and while at it also adds ws2_32 to the .pc file)

cli: add a `git config` command