SHA256: add a SHA256 implementation backend

gcc (mingw) warns when you cast the result of `GetProcAddress`; cast the
results to `void *` before casting them to the actual result.

When GIT_SHA1_WIN32 or GIT_SHA256_WIN32 is used, ensure that we test
both CryptoNG ("cng") and CryptoAPI.

Adding SHA256 support prompted an overdue refactoring of some of the
unnecessary complexity around the CNG/CryptoAPI abstraction.

Add support for a SHA256 hash algorithm, and add the "builtin" SHA256
hash engine (from RFC 6234).

The more generic GIT_ERROR_SHA allows for SHA256 errors as well as SHA1.

Eliminate the `sha1` folder, move it down into `hash` so that future
impelmentations can share common code.

Remove the "generic" implementation; it should never be used; it only
existed for a no-dependencies configuration, and our bundled sha1dc
satisfies that requirement _and_ is correct.

Benchmarking suite

clone: update bitbucket tests

Fix a string concatenation bug when validating extensions

As builtin extensions are evaluated in the latter half of `check_valid_extension`, a string `cfg` is concatenated with the static string 'extension.' and the value from `builtin_extension`, before being compared with the configured value. This string is not being cleared while iterating through the names of the extensions. Because there is currently only one extension ('noop'), the bug was never noticible.

This patch corrects the behavior by clearing the string on each iteration, as is done in the first block.

Some minor fixes for issues discovered by coverity

cmake: export libraries needed to compile against libgit2

Add a benchmark test suite that wraps hyperfine and is suitable for
producing data about test runs of a CLI or A/B testing CLIs.

Allow for options in the `cmake --build` phase, so that callers can
specify (eg) the config type.

Rename our build setup scripts to include the `build` name so that we
can add additional CI setup scripts with no ambiguity.

If users are using us as a direct dependency (via `add_subdirectory`)
then they may want to know the libraries to link to; tell them.

Mistakenly `&&` when we should have `||`d.

When we encounter a situation where we need to exit, simply `return -1`
instead of trying to set `len = -1` and then jumping to the exit
handler, which would erroneously do work based on the `len` value.

If we're safely asserting (and returning an error to the caller), we
should still unlock our mutex.

Now that we safely assert and return, we may need to be in a place where
we need to unlock mutexes or cleanup resources.  Provide
`ASSERT_WITH_CLEANUP` that permits for this behavior by taking a block.

CLI (redux)

Introduce a simple command that emulates `git hash-object`.

Introduce a simple command that emulates `git cat-file`.

Support `help <command>` by re-invoking the command itself with the
`--help` argument.  This allows us to keep the help logic with the
commands itself.

Add a framework for commands to be defined, and add our first one,
"help".  When `git2_cli help` is run, the `cmd_help` function will be
invoked with the remaining command line arguments.  This allows users to
invoke `git2_cli help foo` to get information about the `foo` subcommand.

Our argument parser (https://github.com/ethomson/adopt) includes a
function to print a usage message based on the allowed options.  Omit
this and use a cutom function that understands that we have subcommands
("checkout", "revert", etc) that each have their own options.

Introduce a command-line interface for libgit2.  The goal is for it to
be git-compatible.

1. The libgit2 developers can more easily dogfood libgit2 to find bugs,
   and performance issues.

2. There is growing usage of libgit2's examples as a client; libgit2's
   examples should be exactly that - simple code samples that illustrate
   libgit2's usage.  This satisfies that need directly.

3. By producing a client ourselves, we can better understand the needs
   of client creators, possibly producing a shared "middleware" for
   commonly-used pieces of client functionality like interacting with
   external tools.

4. Since git is the reference implementation, we may be able to benefit
   from git's unit tests, running their test suite against our CLI to
   ensure correct behavior.

This commit introduces a simple infrastructure for the CLI.

The CLI is currently links libgit2 statically; this is because the
utility layer is required for libgit2 _but_ shares the error state
handling with libgit2 itself.  There's no obviously good solution
here without introducing annoying indirection or more complexity.
Until we can untangle that dependency, this is a good step forward.

In the meantime, we link the libgit2 object files, but we do not include
the (private) libgit2 headers.  This constrains the CLI to the public
libgit2 interfaces.