The `ssh_custom_free()` function calls `strlen()` on the `publickey` 
field, which stores binary data, not a null-terminated string. This 
causes a heap buffer overflow when the public key data is not 
null-terminated or contains embedded null bytes.

The `publickey` field stores binary data, as required by the underlying 
`libssh2_userauth_publickey()` function, which accepts a public key 
parameter of the type `const unsigned char*`. 

Use the stored `publickey_len` instead of `strlen()` to determine the 
correct buffer size.

Ensure that our `find_executable` behaves as expected:

* When the executable contains a fully- or partially-qualified filename
  component (eg, `foo/bar`) that `PATH` is not searched; these paths are
  relative to the current working directory.
* An empty segment in `PATH` (on POSIX systems) is treated as the
  current directory; this is for compatibility with Bourne shells.
* When a file exists in `PATH`, it is actually executable (on POSIX)

* Do not search `PATH` for fully- or partially-qualified filenames
  (eg, `foo/bar`)
* Ensure that a file in the `PATH` is executable before returning it

Ensure that when we look for an executable on Windows that we add
executable suffixes (`.exe`, `.cmd`). Without this, we would not support
looking for (eg) `ssh`, since we actually need to identify a file named
`ssh.exe` (or `ssh.cmd`) in `PATH`.

By default, `git_process_new` will no longer try to prepare a single
string to execute with the shell. Instead, by default, arguments remain
parameterized and the command to execute is located within the `PATH`.

The shell can also still optionally be used (so that additional
arguments can be included and variables handled appropriately) but this
is done by keeping arguments parameterized for safety.

This new behavior prevents accidental misuse and potential command-line
injection.

When using `git_process_new` on win32, resolve the path to the
application in the same way that we do on POSIX.

Search `PATH` for command to execute (unless the given executable is
fully qualified). In addition, better match Windows executable lookup
behavior itself (allowing the command to be `foo`, and looking for a
matching `foo.exe` or `foo.cmd`.)

Construct the arguments for the ssh exec as an explicit array, instead
of trying to create a command-line for sh. The latter may use user input
(the remote path) so this may be vulnerable to command injection.

Allow `git_str_puts_escaped` to take an escaping prefix and an escaping
suffix; this allows for more options, including the ability to better
support escaping executed paths.

When sending paths to the remote server, escape them properly.
Escape them with a single quote, followed by the escaped character,
followed by another single quote. This prevents misparsing on the
remote side and potential command injection.

Look for the `GIT_SSH_COMMAND` environment variable and prefer it to
`GIT_SSH`. The `GIT_SSH_COMMAND` will execute via the shell, which is
useful to provide additional arguments.

We specify additional arguments to the ssh executable; as a result, we
specify arguments with `GIT_SSH_COMMAND`.

With a recent upgrade to a newer version of MSVC we now get a bunch of
warnings when two operands use different enum types. While sensible in
theory, in practice we have a couple of non-public enums that extend
public enums, like for example with `GIT_SUBMODULE_STATUS`.

Let's for now disable this warning to unblock our builds. The
alternative would be to add casts all over the place, but that feels
rather cumbersome.