When testing conditional includes we overwrite the repository's config
file with the relevant conditions. This causes us to fully overwrite all
repository configuration, including the repository format version and
any extensions. While the test repository used in this test does not
have any extensions, we will add a reftable-enabled repository that does
rely on the "refStorage" extension eventually.

Fix this by only modifying the relevant config keys.

We have a bunch of checks for properties of the "files" reference
backend:

  - Whether a specific reference has been packed or whether it still
    exists as a loose reference.

  - Whether empty ref directories get pruned.

  - Whether we properly fsync data to disk.

These checks continue to be sensible for that backend, but for any other
backend they plain don't work. Adapt the tests so that we only run them
in case the repository uses the "files" backend.

When initializing the "files" refdb we read a couple of values from the
Git configuration. Unfortunately, this causes a chicken-and-egg problem
when reading configuration with "includeIf.onbranch" conditionals: we
need to instantiate the refdb to evaluate the condition, but we need to
read the configuration to initialize the refdb.

We currently work around the issue by reading the "HEAD" file directly
when evaluating the conditional include. But while that works with the
"files" backend, any other backends that store "HEAD" anywhere else will
break.

Prepare for a fix by deferring reading the configuration. We really only
need to be able to execute `git_refdb_lookup()`, so all we need to
ensure is that we can look up a branch without triggering any config
reads.

With the preceding commit we have refactored the "files" backend so that
it can be both instantiated and used to look up a reference without
reading any configuration. With this change in place we don't cause
infinite recursion anymore when using the refdb to evaluate "onbranch"
conditions.

Refactor the code to use the refdb to look up "HEAD". Note that we
cannot use `git_reference_lookup()` here, as that function itself tries
to normalize reference names, which in turn involves reading the Git
configuration. So instead, we use the lower-level `git_refdb_lookup()`
function, as we don't need the normalization anyway.

Expose a function to read a loose reference. This function will be used
in a subsequent commit to read pseudo-refs on the generic refdb layer.

Regardless of which reference storage format is used, pseudorefs will
always be looked up via the filesystem as loose refs. This is because
pseudorefs do not strictly follow the reference format and may contain
additional metadata that is not present in a normal reference.

We don't honor this in `git_reference_lookup()` though but instead defer
to the refdb to read such references. This obviously works just fine
with the "files" backend, but any other backend would have to grow
custom logic to handle reading pseudorefs.

Refactor `git_reference_lookup_resolved()` so that it knows to always
read pseudorefs as loose references. This allows refdb implementations
to not care about pseudoref handling at all.

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.

…o HEAD

…' into HEAD

…ings' into HEAD

Import the reftable library from commit f1228cd12c1 (reftable: make
REFTABLE_UNUSED C99 compatible, 2025-05-29). This is an exact copy of
the reftable library.

The library will be wired into libgit2 over the next couple of commits.

While the reftable library is mostly decoupled from the Git codebase,
some specific functionality intentionally taps into Git subsystems. To
make porting of the reftable library easier all of these are contained
in "system.h" and "system.c".

Reimplement those compatibility shims so that they work for libgit2.

The reftable writer accidentally uses the Git-specific `QSORT()` macro.
This macro removes the need for the caller to provide the element size,
but other than that it's mostly equivalent to `qsort()`.

Replace the macro accordingly. This incompatibility is a bug in Git that
needs to be fixed upstream.

While perfectly legal, older compiler toolchains complain when
zero-initializing structs that contain nested structs with `{0}`:

	/home/libgit2/source/deps/reftable/stack.c:862:35: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
		struct reftable_addition empty = REFTABLE_ADDITION_INIT;
						 ^~~~~~~~~~~~~~~~~~~~~~
	/home/libgit2/source/deps/reftable/stack.c:707:33: note: expanded from macro 'REFTABLE_ADDITION_INIT'
	#define REFTABLE_ADDITION_INIT {0}
					^

Silence this warning by using `{{0}}` instead.

Wire up the reftable library with CMake. At the current point in time
the library is not yet plugged into libgit2 itself.

While it is possible to pass flags to `reftable_stack_new_addition()` to
alter the behaviour of a stack addition, it is not possible to do so via
`reftable_stack_add()`. Plug this gap.

Wire up the "reftable" storage format via the newly implemented reftable
backend.

Generate test resources for reftables. These resources are basically the
Git repositories we already have, but converted to use the "reftable"
format. For most of the part, this conversion is done by executing `git
refs migrate`.

A couple notes:

  - This require a recent Git upstream version with not-yet-upstreamed
    patches due to a bug in `git refs migrate` with reflogs.

  - The migration command does not yet support repositories with
    worktrees. Those were converted by first removing the worktrees,
    migrating the refs and then recreating them.

  - The HEAD_TRACKER reference in testrepo.git is not recognized as a
    root ref and is thus not automatically migrated.

  - testrepo.git has an empty reflog for refs/heads/with-empty-log that
    does not get migrated.

Wire up reftable tests so that they can be executed by setting the
`CLAR_REF_FORMAT` environment variable. This only catches tests that use
`cl_git_sandbox_init()`, but that should cover most of our tests. So
this infrastructure isn't perfect, but for now it's good enough. We may
want to iterate on it in the future.