Ensure that when a patch application fails (due to a conflict in the
working directory, for example) that we do not half-apply the patch or
otherwise leave the working directory dirty.

This is rather obvious in our current apply implementation (we do a two
step process: one to create the post-image and one to check it out) but
this test is a safety net for future refactoring or improvements.

Return `GIT_EAPPLYFAIL` on patch application failure so that users can
determine that patch application failed due to a malformed/conflicting
patch by looking at the error code.

Ensure that we can apply a patch to the working directory, even to files
that are modified in the index (as long as the working directory
contents match the preimage - such that the working directory is
unmodified from HEAD).

Ensure that by default, when using GIT_APPLY_LOCATION_WORKDIR, that
patch application does not update the index, only the working directory.

Move the commonly-used patch hunks into a single constant location.
This allows us to avoid re-declaring them in each test, and allows
us to compose them to build a larger patch file that includes all
the hunks.

Use the new `git_iterator_foreach` API to validate the workdir against
the expected workdir values instead of using the paired/multi iterator
comparison callback.  This allows us to use the `git_iterator_foreach`
to validate the index as well, instead of assuming that the index and
HEAD must always match.

Introduce a `git_iterator_foreach` helper function which invokes a
callback on all files for a given iterator.

Don't attempt to read the postimage file during a file addition, simply
use an empty buffer as the postimage.  Also, test that we can handle
file additions.

If the file was deleted in the postimage, do not attempt to update the
target.  Instead, ignore it and simply allow it to stay removed in our
computed postimage.  Also, test that we can handle file deletions.

Ensure that we can apply a simple patch to the working directory when we
have parsed it from a patch file.

Introduce a standard test applying a diff to a working directory with no
complications.

Introduce `git_apply`, which will take a `git_diff` and apply it to the
working directory (akin to `git apply`), the index (akin to `git apply
--cached`), or both (akin to `git apply --index`).

The generic `git_reader` interface simplifies `git_apply_tree` somewhat.
Reimplement `git_apply_tree` with them.

Similar to the `git_iterator` interface, the `git_reader` interface will
allow us to read file contents from an arbitrary repository-backed data
source (trees, index, or working directory).

Introduce `git_apply_tree`, which will apply a `git_diff` to a given
`git_tree`, allowing an in-memory patch application for a repository.

Optionally hash the contents of files encountered in the filesystem or
working directory iterators.  This is not expected to be used in
production code paths, but may allow us to simplify some test contexts.

For working directory iterators, apply filters as appropriate, since we
have the context able to do it.

CI: Fix macOS leak detection

README: more CI status badges

ci: Fix some minor issues

Don't prefix the path to the yaml templates - the nightly template
itself is already in the `azure-pipelines` directory.  Instead, just
use the relative path.

POSIX: the CMakeLists.txt configures the test names; when we query
ctest for the test command-line to run, fail if the tests are not
found.

Win32: The CMakeLists.txt configures the test names; when we query
ctest for the test command-line to run, fail if the tests are not
found.

Object parse fixes

Windows CI: fail build on test failure

ci: run all the jobs during nightly builds

Instead of running the oddball builds, run all the builds (the ones
that we always run during PR validation and CI) during a nightly
build for increased coverage.

PowerShell can _read_ top-level variables in functions, but cannot _update_
top-level variables in functions unless they're explicitly prefixed with
`$global`.

The commit message encoding is currently being parsed by the
`git__prefixcmp` function. As this function does not accept a buffer
length, it will happily skip over a buffer's end if it is not `NUL`
terminated.

Fix the issue by using `git__prefixncmp` instead. Add a test that
verifies that we are unable to parse the encoding field if it's cut off
by the supplied buffer length.

We currently do not have any test suites dedicated to parsing commits
from their raw representations. Add one based on `git_object__from_raw`
to be able to test special cases more easily.

When parsing tags, we skip all unknown fields that appear before the tag
message. This skipping is done by using a plain `strstr(buffer, "\n\n")`
to search for the two newlines that separate tag fields from tag
message. As it is not possible to supply a buffer length to `strstr`,
this call may skip over the buffer's end and thus result in an out of
bounds read. As `strstr` may return a pointer that is out of bounds, the
following computation of `buffer_end - buffer` will overflow and result
in an allocation of an invalid length.

Fix the issue by using `git__memmem` instead. Add a test that verifies
parsing the tag fails not due to the allocation failure but due to the
tag having no message.

While the tests in object::tag::read exercises reading and parsing valid
tags from the ODB, they barely try to verify that the parser fails in a
sane way when parsing invalid tags. Create a new test suite
object::tag::parse that directly exercise the parser by using
`git_object__from_raw` and add various tests for valid and invalid tags.

Unfortunately, neither the `memmem` nor the `strnstr` functions are part
of any C standard but are merely extensions of C that are implemented by
e.g. glibc. Thus, there is no standardized way to search for a string in
a block of memory with a limited size, and using `strstr` is to be
considered unsafe in case where the buffer has not been sanitized. In
fact, there are some uses of `strstr` in exactly that unsafe way in our
codebase.

Provide a new function `git__memmem` that implements the `memmem`
semantics. That is in a given haystack of `n` bytes, search for the
occurrence of a byte sequence of `m` bytes and return a pointer to the
first occurrence. The implementation chosen is the "Not So Naive"
algorithm from [1]. It was chosen as the implementation is comparably
simple while still being reasonably efficient in most cases.
Preprocessing happens in constant time and space, searching has a time
complexity of O(n*m) with a slightly sub-linear average case.

[1]: http://www-igm.univ-mlv.fr/~lecroq/string/

strtol removal

 buf::oom tests: use custom allocator for oom failures

Create a custom allocator for the `buf::oom` tests that will fail with
out-of-memory errors in predictable ways.  We were previously trying to
guess the way that various allocators on various platforms would fail
in a way such that `malloc`/`realloc` would return `NULL` (instead of
aborting the application, or appearing suspicious to various
instrumentation or static code analysis tools like valgrind.)

Introduce a fake `malloc` and `realloc` that will return `NULL` on
allocations requesting more than 100 bytes.  Otherwise, we proxy to the
default allocator.  (It's important to use the _default_ allocator, not
just call `malloc`, since the default allocator on Windows CI builds may
be the debugging C runtime allocators which would not be compatible with
a standard `malloc`.)

Provide a utility to reset custom allocators back to their default.
This is particularly useful for testing.

ci: arm docker builds