Ensure that we can apply a delta after renaming a file.

git allows a patch file to contain multiple deltas to the same file:
although it does not produce files in this format itself, this could
be the result of concatenating two different patch files that affected
the same file.

git apply behaves by applying this next delta to the existing postimage
of the file.  We should do the same.  If we have previously seen a file,
and produced a postimage for it, we will load that postimage and apply
the current delta to that.  If we have not, get the file from the
preimage.

Test that a patch can contain two deltas that appear to rename an
initial source file to two different destination paths.  Git creates
both target files with the initial source contents; ensure that we do,
too.

Test that we can apply a patch that renames two different files to the
same target filename.  Git itself handles this scenario in a last-write
wins, such that the rename listed last is the one persisted in the
target.  Ensure that we do the same.

Test a rename from A->B simultaneous with a rename from B->A.

Test that we can rename some file from B->C and then rename some other
file from A->B.  Do this with both exact rename patches (eg `rename from
...` / `rename to ...`) and patches that remove the files and replace
them entirely.

Deltas containing exact renames are special; they simple indicate that a
file was renamed without providing additional metadata (like the
filemode).  Teach the reader to provide the file mode and use the
preimage's filemode in the case that the delta does not provide one.)

When applying to both the index and the working directory, ensure that
the working directory's mode matches the index's mode.  It's not
sufficient to look only at the hashed object id to determine that the
file is unchanged, git also takes the mode into account.

Create a test applying a patch with a rename and a modification of a
file.

Add hunk callback parameter to git_apply__patch to allow hunks to be skipped.

None of the reader implementations actually allocate anything
themselves, so they don't need a free function.  Remove it.

Introduce a callback to patch application that allows consumers to
cancel hunk application.

Test that we can return a non-zero value from the apply delta
callback and it will skip the application of a given delta.

Test that we can return an error from the apply delta callback and the
error code is propagated back to the caller.

Introduce a callback to the application options that allow callers to
add a per-delta callback.  The callback can return an error code to stop
patch application, or can return a value to skip the application of a
particular delta.

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.