Monsters.

`check_symbol_exists` is superior to `check_function_exists`; use it
consistently in our cmake configuration

Not all systems have poll(2); emulate it with select(2).

Make socket I/O non-blocking and add optional timeouts.

Users may now set `GIT_OPT_SET_SERVER_CONNECT_TIMEOUT` to set a shorter
connection timeout. (The connect timeout cannot be longer than the
operating system default.) Users may also now configure the socket read
and write timeouts with `GIT_OPT_SET_SERVER_TIMEOUT`.

By default, connects still timeout based on the operating system
defaults (typically 75 seconds) and socket read and writes block.

Add a test against our custom testing git server that ensures that we
can timeout reads against a slow server.

v0.6.0 of poxygit add support for throttling connections to test
timeouts and low-bandwidth situations.

The `gitno` buffer interface is another layer on top of socket reads.
Abstract it a bit into a "static string" that has `git_str` like
semantics but without heap allocation which moves the actual reading
logic into the socket / stream code, and allows for easier future usage
of a static / stack-allocated `git_str`-like interface.

We lose some error information from the read / write callbacks to
stransport. Store our own error value in the object so that we can
ensure that we rely upon it.

`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