libgit2 has two distinct requirements that were previously solved by
`git_buf`.  We require:

1. A general purpose string class that provides a number of utility APIs
   for manipulating data (eg, concatenating, truncating, etc).
2. A structure that we can use to return strings to callers that they
   can take ownership of.

By using a single class (`git_buf`) for both of these purposes, we have
confused the API to the point that refactorings are difficult and
reasoning about correctness is also difficult.

Move the utility class `git_buf` to be called `git_str`: this represents
its general purpose, as an internal string buffer class.  The name also
is an homage to Junio Hamano ("gitstr").

The public API remains `git_buf`, and has a much smaller footprint.  It
is generally only used as an "out" param with strict requirements that
follow the documentation.  (Exceptions exist for some legacy APIs to
avoid breaking callers unnecessarily.)

Utility functions exist to convert a user-specified `git_buf` to a
`git_str` so that we can call internal functions, then converting it
back again.

This change adds the git_commit_graph_writer_* functions to allow to
write and create `commit-graph` files from `.idx`/`.pack` files or
`git_revwalk`s.

Part of: #5757

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: Use the commit-graph in revwalks

Passes w/ gcc 11 on Fedora x64.

Protip: So you don;t have to suffer,

```
perl -pe 's/(-?(?:0x)?[A-Fa-f0-9]+)([Uu])?[Ll][Ll]/\U$2INT64_C(\E$1)/mg'
```

This change does a medium-size refactor of the git_commit_graph_file and
the interaction with the ODB. Now instead of the ODB owning a direct
reference to the git_commit_graph_file, there will be an intermediate
git_commit_graph. The main advantage of that is that now end users can
explicitly set a git_commit_graph that is eagerly checked for errors,
while still being able to lazily use the commit-graph in a regular ODB,
if the file is present.

This change introduces a function that allows the caller to know whether
the `commit-graph` file has not been modified since it was parsed.

Part of: #5757

This change introduces `git_commit_graph_entry_find()` and
`git_commit_graph_entry_parent()`. These two functions allow a much
faster lookup of commits by ID, since the ODB does not need to be
consulted, the commit object does not need to be inflated, and the
contents of the commit object do not need to be parsed.

Part of: #5757