status: fix handling of filenames with special prefixes

Fix libgit2/libgit2sharp#379
test that suggests tags arent fully peeled during push
Add git_diff_patch_size() API

This adds a new API to get the size in bytes of the diffs in a
git_diff_patch object.
Add hunk/file headers to git_diff_patch_size

This allows git_diff_patch_size to account for hunk headers and
file headers in the returned size.  This required some refactoring
of the code that is used to print file headers so that it could be
invoked by the git_diff_patch_size API.

Also this increases the test coverage and fixes an off-by-one bug
in the size calculation when newline changes happen at the end of
the file.
Make compact output more like core Git
Restore GIT_DIFF_LINE_BINARY usage

This restores the usage of GIT_DIFF_LINE_BINARY for the diff
output line that reads "Binary files x and y differ" so that it
can be optionally colorized independently of the file header.
Don't unload diff data unless loaded
Don't do text diff unless content will be used
Don't check rename if file size difference is huge
Use local variables in hash calc to avoid aliasing
Add rename test that used to be really slow

Before the optimization commits, this test used to take about 20
seconds to run on my machine.  Afterwards, there is still a couple
seconds of data setup, but the actual diff and rename detection
runs in a fraction of a second.
Fix incorrect comment
Fix rename detection for tree-to-tree diffs

The performance improvements I introduced for rename detection
were not able to run successfully for tree-to-tree diffs because
the blob size was not known early enough and so the file signature
always had to be calculated nonetheless.

This change separates loading blobs into memory from calculating
the signature.  I can't avoid having to load the large blobs into
memory, but by moving it forward, I'm able to avoid the signature
calculation if the blob won't come into play for renames.
Make rename detection file size fix better

The previous fix for checking file sizes with rename detection
always loads the blob.  In this version, if the odb backend can
get the object header without loading the whole thing into memory,
then we'll just use that, so that we can eliminate possible rename
sources & targets without loading them.
Fix rename detection to use actual blob size

The size data in the index may not reflect the actual size of the
blob data from the ODB when content filtering comes into play.
This commit fixes rename detection to use the actual blob size when
calculating data signatures instead of the value from the index.

Because of a misunderstanding on my part, I first converted the
git_index_add_bypath API to use the post-filtered blob data size
in creating the index entry.  I backed that change out, but I
kept the overall refactoring of that routine and the new internal
git_blob__create_from_paths API because it eliminates an extra
stat() call from the code that adds a file to the index.

The existing tests actually cover this code path, at least when
running on Windows, so at this point I'm not adding new tests to
cover the changes.
Fix some warnings
Major rename detection changes

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.
Rename test for multiple similar matches

A rename test that illustrates a source matching multiple targets.
Update rename src map for any split src

When using a rename source that is actually a to-be-split record,
we have to update the best-fit mapping data in both the case where
the target is also a split record and the case where the target
is a simple added record.  Before this commit, we were only doing
the update when the target was itself a split record (and even in
that case, the test was slightly wrong).
Rename test for rename from rewrite

A rename test that illustrates a rename from a rewrite.