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.

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

xdiff: move xdiff to 'deps'

meta: the main branch is now v1.7.0

config: return `GIT_ENOTFOUND` for missing programdata

When the programdata path is missing, ensure that we pass down the
`GIT_ENOTFOUND` error to the caller instead of converting it to a
generic `-1`.