Introduce `git_fs_path`, which operates on generic filesystem paths.
`git_path` will be kept for only git-specific path functionality (for
example, checking for `.git` in a path).

libgit2 has two distinct requirements that were previously solved by
`git_buf`.  We require:

1. A general purpose string class that provides a number of utility APIs
   for manipulating data (eg, concatenating, truncating, etc).
2. A structure that we can use to return strings to callers that they
   can take ownership of.

By using a single class (`git_buf`) for both of these purposes, we have
confused the API to the point that refactorings are difficult and
reasoning about correctness is also difficult.

Move the utility class `git_buf` to be called `git_str`: this represents
its general purpose, as an internal string buffer class.  The name also
is an homage to Junio Hamano ("gitstr").

The public API remains `git_buf`, and has a much smaller footprint.  It
is generally only used as an "out" param with strict requirements that
follow the documentation.  (Exceptions exist for some legacy APIs to
avoid breaking callers unnecessarily.)

Utility functions exist to convert a user-specified `git_buf` to a
`git_str` so that we can call internal functions, then converting it
back again.

Ensure that a repository's path (at initialization or open time) is
valid.  On Windows systems, this means that the longest known path
beneath the repository will fit within MAX_PATH: this is a lock file for
a loose object within the repository itself.

Other paths, like a very long loose reference, may fail to be opened
after the repository is opened.  These variable length paths will be
checked when they are accessed themselves.  This new functionality is
done at open to prevent needlessly checking every file in the gitdir
(eg, `MERGE_HEAD`) for its length when we could instead check once at
repository open time.

The init.defaultbranch option may be set, but empty.  In this case, we
should ignore it instead of trying to set our default branch to
`refs/heads/`.

This change:

* Increases MY_ROW_LIMIT to 2M, since it has been failing in #5595's
  tests since it's _super_ close to the limit.
* Calls `git_repository_free()` on a `git_repository` that was being
  leaked only in Windows.
* Marks the global `git_repository` on `tests/repo/init.c` as `NULL`
  after being freed to make any accidental access more noisy.
* Uses `cl_assert_equal_i()` in `test_trace_windows_stacktrace__leaks`
  to make the test failures more actionable.
* Renames the globals in `tests/repo/init.c` so that they don't start
  with an underscore.

As part of a push towards more inclusive language, git is reconsidering
using "master" as the default branch name.  As a first step, this
setting will be configurable with the `init.defaultBranch` configuration
option.  Honor this during repository initialization.

During initialization, we will create an initial branch:

1. Using the `initial_head` setting, if specified;
2. Using the `HEAD` configured in a template, if it exists;
3. Using the `init.defaultBranch` configuration option, if it is set; or
4. Using `master` in the absence of additional configuration.

When initializing a repository, we need to check whether its working
directory supports symlinks to correctly set the initial value of the
"core.symlinks" config variable. The code to check the filesystem is
reusable in other parts of our codebase, like for example in our tests
to determine whether certain tests can be expected to succeed or not.

Extract the code into a new function `git_path_supports_symlinks` to
avoid duplicate implementations. Remove a duplicate implementation in
the repo test helper code.

Our file utils functions all have a "futils" prefix, e.g.
`git_futils_touch`. One would thus naturally guess that their
definitions and implementation would live in files "futils.h" and
"futils.c", respectively, but in fact they live in "fileops.h".

Rename the files to match expectations.

There's quite a lot of supporting code for our templates and they are an
obvious standalone feature. Thus, let's extract those tests into their
own suite to also make refactoring of them easier.

In commit 45f24e787 (git_repository_init: stop traversing at
windows root, 2019-04-12), we have fixed `git_futils_mkdir` to
correctly handle the case where we create a directory in
Windows-style filesystem roots like "C:\repo".

The problem here is an off-by-one: previously, to that commit,
we've been checking wether the parent directory's length is equal
to the root directory's length incremented by one. When we call
the function with "/example", then the parent directory's length
("/") is 1, but the root directory offset is 0 as the path is
directly rooted without a drive prefix. This resulted in `1 == 0 +
1`, which was true. With the change, we've stopped incrementing
the root directory length, and thus now compare `1 <= 0`, which
is false.

The previous way of doing it was kind of finicky any non-obvious,
which is also why the error was introduced. So instead of just
re-adding the increment, let's explicitly add a condition that
aborts finding the parent if the current parent path is "/".

Making this change causes Azure Pipelines to fail the testcase
repo::init::nonexistent_paths on Unix-based systems. This is because we
have just fixed creating directories in the filesystem root, which
previously didn't work. As Docker-based tests are running as root user,
we are thus able to create the non-existing path and will now succeed to
create the repository that was expected to actually fail.

Let's split this up into three different tests:

- A test to verify that we do not create repos in a non-existing parent
  directoy if the flag `GIT_REPOSITORY_INIT_MKPATH` is not set.

- A test to verify that we fail if the root directory does not exist. As
  there is a common root directory on Unix-based systems that always
  exist, we can only test for this on Windows-based systems.

- A test to verify that we fail if trying to create a repository in an
  unwriteable parent directory. We can only test this if not running
  tests as root user, as CAP_DAC_OVERRIDE will cause us to ignore
  permissions when creating files.