Stash workdir correctly when added in the index, modified in the workdir

Fixes

Fixed GIT_DELTA_CONFLICTED not returned in some cases

Add `const` qualifier

racy-git, the missing link

Check the repository version

When stashing the workdir tree, examine the index as well.  Using
a mechanism similar to `git_diff_tree_to_workdir_with_index`
allows us to determine that a file was added in the index and
subsequently modified in the working directory.  Without examining
the index, we would erroneously believe that this file was
untracked and fail to include it in the working directory tree.

Use a slightly modified `git_diff_tree_to_workdir_with_index` in
order to avoid some of the behavior custom to `git diff`.  In
particular, be sure to include the working directory side of a
file when it was deleted in the index.

Ensure that when a file is added in the index and subsequently
modified in the working directory, the stashed working directory
tree contains the actual working directory contents.

Drop `git_diff__merge_like_cgit_reversed`, since it's a copy and
paste mess of slightly incompatible changes.

This is something we do on re-init but not when opening a
repository. This hasn't particularly mattered up to now as the version
has been 0 ever since the first release of git, but the times, they're
a-changing and we will soon see version 1 in the wild. We need to make
sure we don't open those.

git will assume the repository format version is 0 if the value is not
there. Do the same.

If an index entry for a file that is not in HEAD is in conflicted state,
when diffing HEAD with the index, the status field of the corresponding git_diff_delta was incorrectly reported as GIT_DELTA_ADDED instead of GIT_DELTA_CONFLICTED.

This was due to handle_unmatched_new_item() initially setting the status
to GIT_DELTA_CONFLICTED but then overriding it later with GIT_DELTA_ADDED.

Explicitly handle GIT_DELTA_CONFLICTED in git_diff_merge()

This fixes a bug where if a file was in conflicted state in either diff,
it would not always remain in conflicted state in the merged diff.

CRLF

Perform LF->CRLF for core.autocrlf=true on non-Win32 because core
git does.

All platforms do terrible, horrible, no good, very bad translation
when core.autocrlf=true.  It's not just Windows!

Allow files to have mixed line endings instead of skipping processing
on them.

Use statistics (like core git) to control the behavior of the
to workdir CRLF filter.

Support hierarchical test resource data, such that you can have
`tests/resources/foo/bar` and move the `bar` directory in as
a fixture.

Calling `cl_fixture_sandbox` on a path that is not directly beneath
the test resources directory succeeds, placing that directory into
the test fixture.  (For example, `cl_fixture_sandbox("foo/bar")`
will sandbox the `foo/bar` directory as `bar`).

Add support for cleaning up directories created this way, by only
cleaning up the basename (in this example, `bar`) from the fixture
directory.

A corpus of files checked out with Git (Linux, 1.9.1) to ensure that
produce identical data when checking out using a CRLF filter.

A corpus of files checked out with Git for Windows (2.4.1.windows.1)
to ensure that we produce identical data when checking out using a
CRLF filter.

Given a variety of combinations of core.autocrlf settings and
attributes settings, test that we check out data into the working
directory the same as a known-good test resource created by git.git.

Include a shell script that will generate the expected CRLF data,
calling git.git to capture its output as a test resource for the
current platform.

Include the UTF8 and UTF8 BOM tests in the master crlf test
branch for completeness.

Include additional test data for CRLF tests: files with mixed
line endings and binary files.

commit: allow retrieving an arbitrary header field

Write modified index in git_stash_apply()

Even though the file is empty and thus the size in the entry matches, we
should be able to detect it as a difference.

They fit there much better, even though we often check by diffing, it's
about the behaviour of the index.

As we attempt to replicate a situation in which an older checkout has
put a file on disk with different filtering settings from us, set the
timestamp on the entry and file to a second before we're performing the
operation so the entry in the index counts as old.

This way we can test that we're not looking at the on-disk file when the
index has the entry and we detect it as clean.

This allows the user to look up fields which we don't parse in libgit2,
and allows them to access gpgsig or mergetag fields if they wish to
check the signature.

When an entry has a racy timestamp, we need to check whether the file
itself has changed since we put its entry in the index. Only then do we
smudge the size field to force a check the next time around.

When a file on the workdir has the same or a newer timestamp than the
index, we need to perform a full check of the contents, as the update of
the file may have happened just after we wrote the index.

The iterator changes are such that we can reach inside the workdir
iterator from the diff, though it may be better to have an accessor
instead of moving these structs into the header.