Move the location option to an argument, out of the options structure.
This allows the options structure to be re-used for functions that don't
need to know the location, since it's implicit in their functionality.
For example, `git_apply_tree` should not take a location, but is
expected to take all the other options.

Place the entire `git_apply` operation inside an indexwriter, so that we
lock the index before we begin performing patch application.  This
ensures that there are no other processes modifying things in the
working directory.

Test that a mode change is reflected in the working directory or index.

Ensure that we accurately CR/LF filter when reading from the working
directory.  If we did not, we would erroneously fail to apply the patch
because the index contents did not match the working directory contents.

When reading a file from the working directory, ensure that we apply any
necessary filters to the item.  This ensures that we get the
repository-normalized data as the preimage, and further ensures that we
can accurately compare the working directory contents to the index
contents for accurate safety validation in the `BOTH` case.

When applying to both the index and the working directory, ensure that
the index contents match the working directory.  This mirrors the
requirement in `git apply --index`.

This also means that - along with the prior commit that uses the working
directory contents as the checkout baseline - we no longer expect
conflicts during checkout.  So remove the special-case error handling
for checkout conflicts.  (Any checkout conflict now would be because the
file was actually modified between the start of patch application and
the checkout.)

When using a workdir reader, optionally validate that the index contents
match the working directory contents.

Patch application need not be on an unmodified file; applying to an
already changed file is supported provided the patch still applies
cleanly.  Add tests that modifies the contents of a file then applies
the patch and ensures that the patch applies cleanly, and the original
changes are also kept.

Use the preimage as the checkout's baseline.  This allows us to support
applying patches to files that are modified in the working directory
(those that differ from the HEAD and index).  Without this, files will
be reported as (checkout) conflicts.  With this, we expect the on-disk
data when we began the patch application (the "preimage") to be on-disk
during checkout.

We could have also simply used the `FORCE` flag to checkout to
accomplish a similar mechanism.  However, `FORCE` ignores all
differences, while providing a preimage ensures that we will only
overwrite the file contents that we actually read.

Modify the reader interface to provide the OID to support this.

Test application with `GIT_APPLY_LOCATION_BOTH`, which emulates
`git apply --index`, updating both the index and the working directory
with the postimage.

When there's a checkout conflict during apply, that means that the
working directory was modified in a conflicting manner and the postimage
cannot be written.  During application, convert this to an application
failure for consistency across workdir/index/both applications.

Ensure that we can apply to the working directory or the index when the
application target is modified, so long as there are not conflicting
changes to the items.

The preimage file being missing entirely is simply a case of an
application failure; return the correct error value for the caller.

Separate the concerns of applying via checkout and updating the
repository's index.  This results in simpler functionality and allows us
to not build the temporary collection of paths in the index case.

When applying to the index (using `GIT_APPLY_LOCATION_INDEX`), ensure
that items modified in the working directory do not conflict with the
application.

Add a test that adds a new file, and another that removes a file when
applying using `GIT_APPLY_LOCATION_INDEX` to ensure that they work.

We update the index with the new_file side of the delta, but we need to
explicitly remove the old_file path in the case where an item was
deleted or renamed.

Test a simple patch application with `GIT_APPLY_LOCATION_INDEX`, which
emulates `git apply --cached`.

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