Test updated symbolic link creation on Windows.  Ensure that we emulate
Git for Windows behavior.  Ensure that when `core.symlinks=true` is set
in a global configuration that new repositories are created without a
`core.symlinks` setting, and that when `core.symlinks` is unset that
`core.symlinks=false` in set in the repository.  Further ensure that
checkout honors the expected `core.symlinks` defaults on Windows.

Provide a function that allows tests to set up a bespoke global
configuration path.

Teach `load_config` how to load all the configurations except
(optionally) the repository configuration.  This allows the new
repository codepath to load the global/xdg/system configuration paths so
that they can be inspected during repository initialization.

Emulate the Git for Windows `core.symlinks` support.  Since symbolic
links are generally enabled for Administrator (and _may_ be enabled due
to enabling Developer mode) but symbolic links are still sufficiently
uncommon on Windows that Git users are expected to explicitly opt-in to
symbolic links by enabling `core.symlinks=true` in a global (or xdg or
system) configuration.

When `core.symlinks=true` is set globally _and_ symbolic links support
is detected then new repositories created will not have a
`core.symlinks` set.  If `core.symlinks` is _not_ set then no detection
will be performed, and `core.symlinks=false` will be set in the
repository configuration.

Don't try to use `link_size` as an index into a string if `p_readlink`
returned <0.  That will - obviously - fail and we'll write out of
bounds.

Ensure that `core.symlinks` is set correctly.  By default, it is unset,
but it is explicitly set to `false` if the platform was detected to not
support symlinks during repository initialization.

Enable `p_symlink` to actually create symbolic links, not just create a
fake link (a text file containing the link target).

This now means that `core.symlinks=true` works on Windows platforms
where symbolic links are enabled (likely due to running in Developer
Mode).

When testing whether symlinks are correctly checked out, examine the
`core.symlinks` configuration option to determine if symlinks are
supported in a repository, don't simply assume that Windows means that
symbolic links are not supported.

Further, when testing the expected default behavior of `core.symlinks`,
test the filesystem's support to determine if symlinks are supported.

Finally, ensure that `core.symlinks=true` fails on a system where
symlinks are actually not supported.  This aligns with the behavior of
Git for Windows.

To determine the canonical filename for a given path, we previously
looked at the directory entries on POSIX systems and used
GetFinalPathNameByHandle on Windows.  However, GetFinalPathNameByHandle
requires a HANDLE - the results of CreateFile - and you cannot
CreateFile on a symbolic link.

To support finding the canonical path of a symbolic link, simply use the
existing POSIX code to look at the directory entries.

Now that we've updated to WIN32_WINNT version of Vista or better, we
don't need to dynamically load GetFinalPathNameByHandle and can simply
invoke it directly.

Increase the WIN32_WINNT level to 0x0600, which enables support for new
APIs from Windows 6.0 (Vista).  We had previously set this to 0x0501,
which was Windows XP.  Although we removed XP support many years ago,
there was no need to update this level previously.  We're doing so now
explicitly so that we can get support for the `CreateSymbolicLink` API.

docs: fix transparent/opaque confusion in the conventions file

Configuration variables can appear on the same line as the section header

path: export the dotgit-checking functions

cmake: correct comment from libssh to libssh2

We use libssh2.  We do not use libssh.  Make sure to disambiguate them
correctly.

Object parsing fuzzer

These checks are preformed by libgit2 on checkout, but they're also useful for
performing checks in applications which do not involve checkout.

Expose them under `sys/` as it's still fairly in the weeds even for this
library.

While rare and a machine would typically not generate such a configuration file,
it is nevertheless valid to write

    [foo "bar"] baz = true

and we need to deal with that instead of assuming everything is on its own line.

config: Port config_file_fuzzer to the new in-memory backend.

Add a simple fuzzer that exercises our object parser code. The fuzzer
is quite trivial in that it simply passes the input data directly to
`git_object__from_raw` for each of the four object types.

When failing to parse a raw object fromits data, we free the
partially parsed object but then fail to propagate the error to the
caller. This may lead callers to operate on objects with invalid memory,
which will sooner or later cause the program to segfault.

Fix the issue by passing up the error code returned by `parse_raw`.

The standalone driver for libgit2's fuzzing targets makes use of
functions from libgit2 itself. While this is totally fine to do, we need
to make sure to always have libgit2 initialized via `git_libgit2_init`
before we call out to any of these. While this happens in most cases as
we call `LLVMFuzzerInitialize`, which is provided by our fuzzers and
which right now always calls `git_libgit2_init`, one exception to this
rule is our error path when not enough arguments have been given. In
this case, we will call `git_vector_free_deep` without libgit2 having
been initialized. As we did not set up our allocation functions in that
case, this will lead to a segmentation fault.

Fix the issue by always initializing and shutting down libgit2 in the
standalone driver. Note that we cannot let this replace the
initialization in `LLVMFuzzerInitialize`, as it is required when using
the "real" fuzzers by LLVM without our standalone driver. It's no
problem to call the initialization and deinitialization functions
multiple times, though.

Add some more tests for git_futils_rmdir_r and some cleanup

diff_stats: use git's formatting of renames with common directories

ignore unsupported http authentication contexts

auth_context_match returns 0 instead of -1 for unknown schemes to
not fail in situations where some authentication schemes are supported
and others are not.

apply_credentials is adjusted to handle auth_context_match returning
0 without producing authentication context.

submodule: ignore path and url attributes if they look like options

Smart packet security fixes

config_file: properly ignore includes without "path" value

These can be used to inject options in an implementation which performs a
recursive clone by executing an external command via crafted url and path
attributes such that it triggers a local executable to be run.

The library is not vulnerable as we do not rely on external executables but a
user of the library might be relying on that so we add this protection.

This matches this aspect of git's fix for CVE-2018-17456.