Allow users to specify additional repository extensions that they want
to support.  For example, callers can specify that they support
`preciousObjects` and then may open repositories that support
`extensions.preciousObjects`.

Similarly, callers may opt out of supporting extensions that the library
itself supports.

Working directory path validation

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.

We already do this in repo_init_head

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.

Update the test cases to check the `git_repository_open` return code.