Provide our own url parser, so that we can handle Google Code's "fun"
URLs that have a userinfo with an `@` in it. 😢

The url::scp::invalid_addresses test attempts to test an invalid IPv6
address. It does not, it calls the regular URL parsing function which
treats it like a possibly invalid scheme.

repo: allow administrator to own the configuration

status: update documentation for default options

config: update config entry iteration lifecycle

Update our ownership checks that were introduced in libgit2 v1.4.3
(to combat CVE 2022-24765). These were not compatible with git's; git
itself allows administrators to own the path. Our checks now match
this behavior.

Look for `getentropy` and flag its existence.

transport: introduce `git_transport_smart_remote_connect_options`

Snuck in during refactoring; let's get rid of it.

A couple of simplications around mwindow

Add a .clang-format with our style

Co-authored-by: Edward Thomson <ethomson@github.com>

CLI: progress updates

refs: fix missing error message

docs: fix couple of typos

revparse: Remove error-prone, redundant test

midx: do not verify the checksum on load

Avoid too much flashing on the console with updates about throughput.
Only update throughput once a second.

Include test results data in CI

midx: fix large offset table check.

Add link to Tcl bindings for libgit2

chore(docs): Add Pharo to language bindings

Though both are correct, this makes it clear that we're dealing with
the same value.

It's insufficient to only check if the offset high order bit is set, we
must also check to see if object_large_offsets are in use.

This bug is causing objects to appear missing because they can't be
found in the index.

Avoid mismatches between the container uid/gid and the actions runner,
build the container with the actions runner's uid/gid

Originally introduced in: 776a6a8e

This test case has recently been fixed in bdab2238, but that fix will only last for a year. Next year the same problem will crop up and the test will need to be re-edited.

This is not ideal as
- This test case becomes an unnecessary burden for developers
- Downstream distros or even just users who want to build older versions of libgit2 are guaranteed to have this test fail

Furthermore, this test case is entirely unnecessary, as the functionality that was originally (see 776a6a8e) intended to be tested is well-covered by subsequent tests which specify a date instead of a "x ago" specification.

This is something we only want to do during explicit verification rather than on
every load.

Verifying does not seem like a big deal when we're running with test workloads
but once your `multi-pack-index` reaches gigabytes, we spend more time hashing
this than doing any work.