Omitting an entrypoint.sh to configure the container and instead
depending on docker primitives allows us to be more portable.  (If a
distribution uses a different mechanism for adding users, we need not
have multiple entrypoint.sh files or invariants within it; instead we
can configure that in the dockerfile itself along with all the other
distribution specific components.)

tests: reset odb backend priority

Fix one memory leak in master

Introduce GIT_OPT_SET_ODB_LOOSE_PRIORITY and GIT_OPT_SET_ODB_PACKED_PRIORITY
to allow overriding the default priority values for the default ODB
backends. Libgit2 has historically assumed that most objects for long-
running operations will be packed, therefore GIT_LOOSE_PRIORITY is
set to 1 by default, and GIT_PACKED_PRIORITY to 2.
When a client allows libgit2 to set the default backends, they can
specify an override for the two priority values in order to change
the order in which each ODB backend is accessed.

There was one test that wasn't correctly disposing of the repository.

Document `GIT_STATUS_OPT_INCLUDE_UNREADABLE`, and some minor cleanups.

common.h: use inline when compiling for C99 and later

Support reading attributes from a specific commit

len, array -> array, len

This change introduces a new API function
`git_graph_reachable_from_any()`, that answers the question whether a
commit is reachable from any of the provided commits through following
parent edges.

This function can take advantage of optimizations provided by the
existence of a `commit-graph` file, since it makes it faster to know
whether, given two commits X and Y, X cannot possibly be an reachable
from Y.

Part of: #5757

commit-graph: Introduce `git_commit_list_generation_cmp`

This change makes calculations of merge-bases a bit faster when there
are complex graphs and the commit times cause visiting nodes multiple
times. This is done by visiting the nodes in the graph in reverse
generation order when the generation number is available instead of
commit timestamp. If the generation number is missing in any pair of
commits, it can safely fall back to the old heuristic with no negative
side-effects.

Part of: #5757

commit-graph: Use the commit-graph in revwalks

[Submodule] Git submodule dup

Provide a mechanism to filter using attribute data from a specific
commit (making use of `GIT_ATTR_CHECK_INCLUDE_COMMIT`).

Introduce `GIT_ATTR_CHECK_INCLUDE_COMMIT`, which like 4fd5748c allows
attribute information to be read from files in the repository.  4fd5748c
always reads the information from HEAD, while
`GIT_ATTR_CHECK_INCLUDE_COMMIT` allows users to provide the commit to
read the attributes from.

When looking up an attribute file in a commit, we can cache a
nonexistent attribute file indefinitely (since a commit could not
somehow later contain an attribute file).  Cache an empty buffer when an
attribute file does not exist in a given commit.

Allow filter users to provide an options structure instead of simply
flags.  This allows for future growth for filter options.

Filters use a short-lived structure to keep state during an operation to
allow for caching and avoid unnecessary reallocations.  This was
previously called the "filter options", despite the fact that they
contain no configurable options.  Rename them to a "filter session" in
keeping with an "attribute session", which more accurately describes
their use (and allows us to create "filter options" in the future).

Allow more advanced attribute queries using a `git_attr_options`, and
extended functions to use it.  Presently there is no additional
configuration in a `git_attr_options` beyond the flags, but this is for
future growth.

The attribute source object is now the type and the path.

We may want to extend the attribute source; use a structure instead of
an enum.

The enum `git_attr_file_source` is better suffixed with a `_t` since
it's a type-of source.  Similarly, its members should have a matching
name.

Optional stricter allocation checking (for `malloc(0)` cases)

Co-authored-by: lhchavez <lhchavez@lhchavez.com>