This is much of the plumbing for the object database to support SHA256,
and for objects to be able to parse SHA256 versions of themselves.

Teach the packfile machinery to cope with SHA256.

In clar, an underscore is meaningful; avoid using it incorrectly /
unnecessarily.

This is a conversion of the testrepo.git to SHA256 support.

Ensure that we maintain the `core.repositoryFormatVersion` value instead
of always overwriting it with the default.

Provide an internal function to set the repository's `objectformat`,
both in the internal object and in the configuration.

Teach the repository about the `objectformat` extension, supporting
`sha1` always and `sha256` when the experimental sha256 support is
active.

Support OpenSSL3: add OpenSSL deprection warning compatibility flag

Add `OPENSSL_API_COMPAT=0x10100000L` since we use the now-deprecated
low-level hash functions.

ci: always create test summaries, even on failure

When the dependent jobs fail -- possibly due to test failures -- we
should still produce the job summary that shows those test failures.

tests: update clar test runner

Abstract time counter for tests; use gettimeofday on Unix and
GetTickCount on Windows.

Update to the latest main version of clar, which includes improved xml
summary output.

src: hide unused hmac() prototype

The builtin hash uses the code verbatim from rfc6234, including
prototypes for functions that we don't use (like hmac). Remove all
unused prototypes to avoid collisions with things that an operating
system might provide (like hmac).

It conflicts with NetBSD's in its libc.

Closes #6457

push: use resolved oid as the source

211c9719 attempts to use the parsed OID
but inverted the arguments to `git_oid_cpy`.

push: revparse refspec source, so you can push things that are not refs

thread: avoid warnings when building without threads

transport: fix capabilities calculation

ci: update version numbers of actions

`git_clone` checks for existence of (non-empty) directories that would clash with what is about to be cloned.

This is problematic when cloning submodules since they make sense in the context of a parent module, so they should not use the current working dir.

Since in `git_submodule_update` we clone the submodule only when it is not yet initialized we do not need to perform directory checks.

Fixes #6433: git_submodule_update fails to update configured but missing submodule

This looks like a typo to me, from what i can see these lines were
added at the same time and because of how capabilities are calculated,
it's likely that this code will work in situations where these
capabilities were the last ones.

If a submodule has been configured but not yet added, do not try to update it.

Issue #6433: git_submodule_update fails to update configured but missing submodule

Verify that trying to update submodule which has been configured but not added does return an error.

Issue #6433: git_submodule_update fails to update configured but missing submodule