Make path.[ch] contain pure utility functions that do not know about
public-facing libgit2 objects, including `git_repository`.

Provide a class that will display progress information to the console.
Initially, it contains callbacks for fetch progress and checkout
progress.

Set up a framework for subcommands, and introduce the first, "help".

Help will display the commands available, and information about the
help command itself.

Commands are expected to provide their own usage and help information,
which the help command will proxy to when necessary.

Our options parsing system can also be used as the basis for displaying
command-line usage.  Add usage information, using knowledge of the
console (if we're attached to one) for wrapping nicely.

As we consume parts of the libgit2 utility functions (like `git_buf`),
we will inevitably need to allocate.  Since we re-use the libgit2
allocation functions - but linked into our application - we'll need
to configure our allocation strategy ahead of time.

Introduce a command-line interface for libgit2.  The goal is to be
git-compatible, so that:

1. By creating a git client ourselves, we can understand the needs of
   git clients and produce a common "middleware" for commonly-used
   pieces of client functionality.  For example: interacting with
   other command-line tools, like filter drivers or merge drivers.
   This can assist other git clients.

2. We can benefit from git's unit tests, running their test suite
   against our own CLI to ensure correct behavior.

3. We can easily benchmark ourselves against git to understand where we
   are poorly performing, by running identical commands between git and
   ourselves.

4. We can easily A/B test ourselves against git, at least for read-only
   operations, which will ensure that we are producing identical output.

This commit introduces a simple infrastructure for the CLI.

Introduce libgit2client, a client "middleware" library.  This is an
experimental set of utility functions and classes for client software
that builds on top of libgit2.

This library might contain - for example - code that invokes filters or
other tools.  This is incredibly useful to share and reuse among
consumers but should be excluded from libgit2 itself.  Users may,
understandably, not want code that executes arbitrary other commands in
libgit2 itself.