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

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 the UTF8 and UTF8 BOM tests in the master crlf test
branch for completeness.

When ticking over one second, it can happen that the actual time ticks
over the same second between the time that we undermine our own race
protections and the time in which we perform the index update. Such
timing would make the time in the entries match the index' timestamp and
we have not gained anything.

Ticking over five seconds makes it so that if real-time rolls over that
second, our index is still ahead. This is still suboptimal as we're
dealing with timing, but five seconds should be long enough for any
reasonable test runner to finish the tests.

Provide functionality to set the time on a filesystem entry,
using utimes or futimes on POSIX type systems or SetFileTime
on Win32.

These tests want to test that we don't recalculate entries which match
the index already. This is however something we force when truncating
racily-clean entries.

Tick the index forward as we know that we don't perform the
modifications which the racily-clean code is trying to avoid.

In order to avoid racy-git, we zero out the file size for entries with
the same timestamp as the index (or during the initial checkout). This
is the case in a couple of crlf tests, as the code is fast enough to do
everything in the same second.

As we know that we do not perform the modification just after writing
out the index, which is what this is designed to work around, tick the
mtime of the index file such that it doesn't agree with the files
anymore, and we do not zero out these entries.

We do not error on "merge conflicts"; on the contrary, merge conflicts
are a normal part of merging.  We only error on "checkout conflicts",
where a change exists in the index or the working directory that would
otherwise be overwritten by performing the checkout.

This *may* happen during merge (after the production of the new index
that we're going to checkout) but it could happen during any checkout.