Avoid passing a `NULL` ptr to `memcpy` -- that's UB (even if size is 0)

Test that `git_buf` correctly fails if no more bytes can be allocated.
This is mostly for demonstration purposes.

In several circumstances, we get bug reports about things that happen in
situations where the environment is quite limited with regards to
available memory. While it's expected that functionality will fail if
memory allocations fail, the assumption is that we should do so in a
controlled way. Most importantly, we do not want to crash hard due to
e.g. accessing NULL pointers.

Naturally, it is quite hard to debug such situations. But since our
addition of pluggable allocators, we are able to implement allocators
that fail in deterministic ways, e.g. after a certain amount of bytes
has been allocated. This commit does exactly that.

To be able to properly keep track of the amount of bytes currently
allocated, allocated pointers contain tracking information. This
tracking information is currently limited to the number of bytes
allocated, so that we can correctly replenish them on calling `free` on
the pointer. In the future, it would be feasible to extend the tracked
information even further, e.g. by adding information about file and line
where the allocation has been performed. As this introduced some
overhead to allocations though, only information essential to limited
allocations is currently tracked.

Remove the number of functions that custom allocator users need to
provide; nobody should need to implement `substrdup`. Keep it to the
basics that are actually _needed_ for allocation (malloc, realloc,
free) and reimplement the rest ourselves.

In addition, move the failure check and error setting _out_ of the
custom allocators and into a wrapper so that users don't need to deal
with this. This also allows us to call our allocator (without the
wrapper) early so that it does not try to set an error on failure, which
may be important for bootstrapping.

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.