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.

Prefer `off64_t` internally.

Use the new object_type enumeration names within the codebase.

The `git_walk_objects` structure is currently only being used inside of
the pack-objects.c file, but being declared in its header. This has
actually been the case since its inception in 04a36feff (pack-objects:
fill a packbuilder from a walk, 2014-10-11) and has never really
changed.

Move the struct declaration into pack-objects.c to improve code
encapsulation.

use consistent names for the #include / #define header guard pattern.

After 1cd65991, we were passing a pointer to an `unsigned long` to
a function that now expected a pointer to a `size_t`.  These types
differ on 64-bit Windows, which means that we trash the stack.

Use `size_t`s in the packbuilder to avoid this.

This is useful to send to the client while we're performing the work.

The reporting function has a force parameter which makes sure that we
do send out the message of 100% completed, even if this comes before the
next udpate window.

Most use-cases for the object packer communicate in terms of commits
which each side has. We already have an object to specify this
relationship between commits, namely git_revwalk.

By knowing which commits we want to pack and which the other side
already has, we can perform similar optimisations to git, by marking
each tree as interesting or uninteresting only once, and not sending
those trees which we know the other side has.