When no payload is set for `crlf_apply` we try to compute the
crlf attributes ourselves with `crlf_check`. When the function
determines that the current file does not require any treatment
we return the GIT_PASSTHROUGH error code without actually
allocating the out-pointer, which indicates the file should not
be passed through the filter.

The `crlf_apply` function explicitly checks for the
GIT_PASSTHROUGH return code and ignores it. This means we will
try to apply the crlf-filter to the current file, leading us to
dereference the unallocated payload-pointer.

Fix this obviously incorrect behavior by not treating
GIT_PASSTHROUGH in any special way. This is the correct thing to
do anyway, as the code indicates that the file should not be
passed through the filter.

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

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

For consistency with the rest of the library, where an opt is an
options *structure*.

Git for Windows 1.9.4 changed the behavior when the text=auto
attribute is specified and core.autocrlf=false.  Previous observed
behavior would *not* filter files when going into the working
directory, the new behavior *does* filter.  Update our behavior to match.

If you enabled core.safecrlf on an LF-ending platform, we would
error even for files with all LFs.  We should only be warning on
irreversible mappings, I think.

Diff and status do not want core.safecrlf to actually raise an
error regardless of the setting, so this extends the filter API
with an additional options flags parameter and adds a flag so that
filters can be applied with GIT_FILTER_OPT_ALLOW_UNSAFE, indicating
that unsafe filter application should be downgraded from a failure
to a warning.