The diff code was using an "ignored_prefix" directory to track if
a parent directory was ignored that contained untracked files
alongside tracked files. Unfortunately, when negative ignore rules
were used for directories inside ignored parents, the wrong rules
were applied to untracked files inside the negatively ignored
child directories.

This commit moves the logic for ignore containment into the workdir
iterator (which is a better place for it), so the ignored-ness of
a directory is contained in the frame stack during traversal.  This
allows a child directory to override with a negative ignore and yet
still restore the ignored state of the parent when we traverse out
of the child.

Along with this, there are some problems with "directory only"
ignore rules on container directories.  Given "a/*" and "!a/b/c/"
(where the second rule is a directory rule but the first rule is
just a generic prefix rule), then the directory only constraint
was having "a/b/c/d/file" match the first rule and not the second.
This was fixed by having ignore directory-only rules test a rule
against the prefix of a file with LEADINGDIR enabled.

Lastly, spot checks for ignores using `git_ignore_path_is_ignored`
were tested from the top directory down to the bottom to deal with
the containment problem, but this is wrong. We have to test bottom
to top so that negative subdirectory rules will be checked before
parent ignore rules.

This does change the behavior of some existing tests, but it seems
only to bring us more in line with core Git, so I think those
changes are acceptable.

Reduce excessive OID calculation for diff and stat

commit: safer commit creation with reference update

Trying to find other issues where tests may not clean up quite
properly when they are through...

There are a few tests that set up a fake home directory and a
fake GLOBAL search path so that we can test things in global
ignore or attribute or config files.  This cleans up that code to
work more robustly even if there is a test failure.  This also
fixes some valgrind warnings where scanning search paths for
separators could end up doing a little bit of sketchy data access
when coming to the end of search list.

There were a couple of "init_opts()" functions a few more cases
of structure initialization that I somehow missed.

Use an unsigned int for the version and add a helper macro so the
code is simplified (and so the error message is a common string).

Since git_diff_init_options was introduced, remove this old fn.

This is a proposed adjustment to the trace APIs.  This makes the
trace levels into a bitmask so that they can be selectively enabled
and adds a callback-level payload, plus a message-level payload.

This makes it easier for me to a GIT_TRACE_PERF callbacks that
are simply bypassed if the PERF level is not set.

This adds an option to refresh the stat cache while generating
status.  It also rips out the GIT_PERF stuff I had an makes use
of the trace API to keep statistics about what happens during diff.

When diff is scanning the working directory, if it finds a file
where it is not sure if the index entry matches the working dir,
it will recalculate the OID (which is pretty expensive).  This
adds a new flag to diff so that if the OID calculation finds that
the file actually has not changed (i.e. just the modified time was
altered or such), then it will refresh the stat cache in the index
so that future calls to diff will not have to check the oid again.

This reorganized the diff OID calculation to make it easier to
correctly update the stat cache during a diff once the flags to
do so are enabled.

This includes marking the path of a git_index_entry as const so
we can make a "fake" git_index_entry with a "const char *" path
and not get warnings.  I was a little surprised at how unobtrusive
this change was, but I think it's probably a good thing.

When we think the stat cache in the index seems valid and the size
or mode of a file has definitely changed, then don't bother trying
to recalculate the OID of the workdir bits to confirm that it is
modified - just accept that it is modified.

This can result in files that show as modified with no actual diff,
but the behavior actually appears to match Git on the command line.

This also includes a minor optimization to not perform a submodule
lookup on the ".git" directory itself.

See https://github.com/libgit2/libgit2/pull/2321#issuecomment-42039673
We may rollback once we found something more reliable

Make examples/status.c compile on Windows

Make ** pattern eat trailing slash

This allows "foo/**/*.html" to match "foo/file.html"

Solaris!

Assorted CMake fixups

cygwin also doesn't have qsort_r

An empty string is not a valid number, and some shells complain.

Check instead if $COVERITY is non-empty, which is a common convention
and what we're doing anyway.

If it's not documented, it doesn't show up in the docs (and we really
should document, anyway).

It reportedly works. It does not however work when cross-compiling on
Travis, so let's disable it there.

This fixes #2311.

This fixes #2118

The point of this phase is to know what we have and not. Show the user a
clear indication of what we have.

The current version of the commit creation and amend function are unsafe
to use when passing the update_ref parameter, as they do not check that
the reference at the moment of update points to what the user expects.

Make sure that we're moving history forward when we ask the library to
update the reference for us by checking that the first parent of the new
commit is the current value of the reference. We also make sure that the
ref we're updating hasn't moved between the read and the write.

Similarly, when amending a commit, make sure that the current tip of the
branch is the commit we're amending.

MidnightBSD may also not have strnlen

Make the build CMake 2.6 compatible

Keep the deflate buffer from ballooning up