clar: add tap output option

diff::parse: don't include `diff.h`

We don't call any internal functions in the test; we don't need to
include `../src/diff.h`.

release script: fix typo

Add an output abstraction layer, with a single output format, "clap",
the clar protocol, which is the current output format for clar.

We want to parse arguments before we start printing any output; the
arguments themselves may impact the way we display that output.

tests: offer exact name matching with a `$` suffix

httpclient: support googlesource

git_packbuilder_write: Allow setting path to NULL to use the default path

mempack: Use threads when building the pack

When using `-s` to specify a particular test, it will do a prefix match.
Thus, `-sapply::both::rename_a_to_b_to_c` will match both a test named
`test_apply_both__rename_a_to_b_to_c` and a test that begins with that
name, like `test_apply_both__rename_a_to_b_to_c_exact`.

Permit a trailing `$` to `-s` syntax.  This allows a user to specify
`-sapply::both::rename_a_to_b_to_c$` to match _only_ the
`test_apply_both__rename_a_to_b_to_c` function.

We already filter to ensure that the given prefix matches the current
test name.  Also ensure that the length of the test name matches the
length of the filter, sans trailing `$`.

clar: use internal functions instead of /bin/cp and /bin/rm

Similar to how clar has used `/bin/cp` to copy files, it's used
`/bin/rm` to remove them.  This has similar deficiencies; meaning that
leaks is noisy and it's slow.  Move it to an internal function.

clar has historically shelled out to `/bin/cp` to copy test fixtures
into a sandbox.  This has two deficiencies:

1. It's slower than simply opening the source and destination and
   copying them in a read/write loop.  On my Mac, the `/bin/cp` based
   approach takes ~2:40 for a full test pass.  Using a read/write loop
   to copy the files ourselves takes ~1:50.

2. It's noisy.  Since the leak detector follows fork/exec, we'll end up
   running the leak detector on `/bin/cp`.  This would be fine, except
   that the leak detector spams the console on startup and shutdown, so
   it adds a _lot_ of additional information to the test runs that is
   useless.  By not forking and using this internal system, we see much
   less output.

strarray refactoring

The httpclient implementation keeps a `read_buf` that holds the data
in the body of the response after the headers have been written.  We
store that data for subsequent calls to `git_http_client_read_body`.  If
we want to stop reading body data and send another request, we need to
clear that cached data.

Clear the cached body data on new requests, just like we read any
outstanding data from the socket.

When `git_http_client_read_body` is invoked, it provides the size of the
buffer that can be read into.  This will be set as the parser context's
`output_size` member.  Use this as an upper limit on our reads, and
ensure that we do not read more than the client requests.