We are allowed to call `git_repository__cleanup` multiple times, and this
happens e.g. in rugged if we want to free up resources before GC gets around to
them.

This means that we cannot leave dangling pointers in it, which we were doing
with the grafts. Fix this by setting the pointers to NULL after freeing the resources.

git_oid_tostr_s could fail if thread-local state initialization fails.
In that case, it will now return `NULL`.  Callers should check for
`NULL` and propagate the failure.

Users should provide us an array of object ids; we don't need a separate
type. And especially, we should not be mutating user-providing values.
Instead, use `git_oid *` in the shallow code.

The semantics of `from_file` are weird - it looks like a function that
just opens a file, but it actually inspects the pointer, which is
unexpected and could make things very crashy.

Make an `open` function that just does an open, and move the magic to
`open_or_refresh` whose name better indicates that it may do weird
stuff.

... otherwise git_tree__parse_raw() will fail to obtain
the correct oid size, which causes the entire parse to fail.

The opt mechanism isn't _really_ meant to be for feature flags, and it's
weird to feature flag shallow / unshallow at all.

When the repository is opened with `GIT_REPOSITORY_OPEN_FROM_ENV`, honor
the `GIT_CONFIG_GLOBAL`, `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_NOSYSTEM`
environment variables.

When the repository is opened with `GIT_REPOSITORY_OPEN_FROM_ENV`, honor
the `GIT_COMMON_DIR` environment variable.

When the repository is opened with `GIT_REPOSITORY_OPEN_FROM_ENV`, honor
the `GIT_WORK_TREE` environment variable.

Remove the `_git_repository_open_ext_from_env` and make it part of the
general repository opening code path. This removes the re-entrancy, and
standardizes things like index and config opening to a single place
again so that we have predictable ordering of the opening procedure.

"Could not find repository from ..." doesn't make sense. "Could not find
repository _at_ ..." does not indicate that we walked down the path
hierarchy, but at least it's more correct.

If a user attempts to add a custom extension that the system already
supports, or that is already in their list of custom extensions, de-dup
it.

Git for Windows does some truly bizarre things with
paths that start with a forward slash; and expects you
to escape that with `%(prefix)`. This syntax generally
means to add the prefix that Git was installed to -- eg
`/usr/local` -- unless it's an absolute path, in which
case the leading `%(prefix)/` is just removed. And Git
for Windows expects you to use this syntax for absolute
Unix-style paths (in "Git Bash" or Windows Subsystem for
Linux).

Worse, the behavior used to be that a leading `/` was
not absolute. It would indicate that Git for Windows
should add the prefix. So `//` is required for absolute
Unix-style paths. Yes, this is truly horrifying.

Emulate that behavior, I guess, but only for absolute
paths. We won't deal with the Git install prefix. Also,
give WSL users an escape hatch where they don't have to
think about this and can use the literal path that the
filesystem APIs provide (`//wsl.localhost/...`).

With some paths on Win32, we cannot identify the owner because it's on a
file share (WSL2 or UNC). In that case, don't fail, but identify that
the current user does not own the path. This matches Git for Windows
behavior.

This is much of the plumbing for the object database to support SHA256,
and for objects to be able to parse SHA256 versions of themselves.

Ensure that we maintain the `core.repositoryFormatVersion` value instead
of always overwriting it with the default.

Provide an internal function to set the repository's `objectformat`,
both in the internal object and in the configuration.

Teach the repository about the `objectformat` extension, supporting
`sha1` always and `sha256` when the experimental sha256 support is
active.

Signed-off-by: Sven Strickroth <email@cs-ware.de>