`git__timer` is now `git_time_monotonic`, and returns milliseconds
since an arbitrary epoch.

Using a floating point to store the number of seconds elapsed was
clever, as it better supports the wide range of precision from the
different monotonic clocks of different systems. But we're a version
control system, not a real-time clock.

Milliseconds is a good enough precision for our work _and_ it's the
units that system calls like `poll` take and that our users interact
with.

Make `git_time_monotonic` return the monotonically increasing number
of milliseconds "ticked" since some arbitrary epoch.

Thread-local storage: handle failure cases

Now that we've reduced the usage of GIT_THREADSTATE, remove it entirely
in favor of git_threadstate_get().

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.

Thread-local storage data may fail to initialize; in this case, do not
try to set the error message into it.  When the thread state has not
been initialized, return a hardcoded message to that affect.

actions: simplify execution with composite action

Update xdiff to git 2.40.1's version

Work around -Werror problems when detecting qsort variants

Introduce `check_prototype_definition_safe` that is safe for `Werror`
usage.

`QSORT_R` and `QSORT_S` -> `QSORT`

Add `GIT_UNUSED_ARG` which is an attribute for arguments, for
compatibility with dependencies.

Shallow (#6396) with some fixes from review

The `depth` field is suitable to specify unshallowing; provide an enum
to aide in specifying the `unshallow` value.

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.

If `ENABLE_WERROR` is on, the CMake configure tests for the `qsort_r`
and `qsort_s` variants may fail due to warnings about unused functions
or unused parameters. These warnings can be ignored, so disable them
specifically for running those tests.

util: detect all possible qsort_r and qsort_s variants

As reported in https://bugs.freebsd.org/271234, recent versions of
FreeBSD have adjusted the prototype for qsort_r() to match the POSIX
interface. This causes libgit2's CMake configuration check to fail to
detect qsort_r(), making it fall back to qsort_s(), which in libgit2
also has an incompatible interface. With recent versions of clang this
results in a "incompatible function pointer types" compile error.

Summarizing, there are four variations of 'qsort-with-context':
* old style BSD qsort_r(), used in FreeBSD 13 and earlier, where the
  comparison function has the context parameter first
* GNU or POSIX qsort_r(), also used in FreeBSD 14 and later, where the
  comparison function has the context parameter last
* C11 qsort_s(), where the comparison function has the context parameter
  last
* Microsoft qsort_s(), where the comparison function has the context
  parameter first

Add explicit detections for all these variants, so they get detected as
(in the same order as above):

* `GIT_QSORT_R_BSD`
* `GIT_QSORT_R_GNU`
* `GIT_QSORT_S_C11`
* `GIT_QSORT_S_MSC`

An additional complication is that on FreeBSD 14 and later, <stdlib.h>
uses the C11 _Generic() macro mechanism to automatically select the
correct qsort_r() prototype, depending on the caller's comparison
function argument. This breaks CMake's check_prototype_definition()
functionality, since it tries to redefine the function, and _Generic
macro is expanded inline causing a compile error.

Work around that problem by putting the function names in parentheses,
to prevent the preprocessor from using a macro to replace the function
name.

Also, in `git__qsort_r()`, change the `#if` order so the variants that
do not have to use glue are preferred.

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.

Depth of `0` should indicate full depth. Disallow negative values (they
may have a future meaning) and use `0` as the default.

Don't mix parsing by hand and using `git_parse` to parse.

Use SHA256 for file checksums. SHA1 makes no sense as a default in 2023.

Given that we're just looking at a file checksum to see if it's changed,
this does not need to take repository's OID type into account or
otherwise be configurable.

Looks like a double-free here.

Support SHA256 in git_repository_wrap_odb

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

Teach the smart transport more about oid types, instead of assuming SHA1.

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

sha256: less hardcoded SHA1 types and lengths