The git_buf_text_gather_stats call returns a boolean indicating if
the file looks like binary data.  That shouldn't be an error; it
should be used to skip CRLF processing though.

This updates clar to the version without cl_assert_equal_sz and
then adds a new version of that macro the clar_libgit2.h.  The new
version works around a strange issue that seemed to be arising on
release builds with VS 10 64-bit builds.

There were a lot of places in the test code base that were creating
a commit from the index on the current branch.  This just adds a
helper to handle that case pretty easily.  There was only one test
where this change ended up tweaking the test data, so pretty easy
and mostly just a cleanup.

These are a couple of new clar helpers for testing that a file
has expected contents that I extracted from the checkout code.

Actually wrote this as part of an abandoned earlier attempt at a
new filters API, but it will be useful now for some of the tests
I'm going to write.

Some windows tests were failing

It seems that libgit2 is correctly applying the umask when
initializing a repository from a template and when creating new
directories during checkout, but the test suite is not accounting
for possible variations due to the umask.  This updates that so
that the test suite will work regardless of the umask.

After doing further profiling, I found that a lot of time was
being spent attempting to insert hashes into the file hash
signature when using the rolling hash because the rolling hash
approach generates a hash per byte of the file instead of one
per run/line of data.

To optimize this, I decided to convert back to a run-based file
signature algorithm which would be more like core Git.

After changing this, a number of the existing tests started to
fail.  In some cases, this appears to have been because the test
was coded to be too specific to the particular results of the file
similarity metric and in some cases there appear to have been bugs
in the core rename detection code where only by the coincidence
of the file similarity scoring were the expected results being
generated.

This renames all the variables in the core rename detection code
to be more consistent and hopefully easier to follow which made it
a bit easier to reason about the behavior of that code and fix the
problems that I was seeing.  I think it's in better shape now.

There are a couple of tests now that attempt to stress test the
rename detection code and they are quite slow.  Most of the time
is spent setting up the test data on disk and in the index.  When
we roll out performance improvements for index insertion, it
should also speed up these tests I hope.