This renames git_vector_free_all to the better git_vector_free_deep
and also contains a couple of memory leak fixes based on valgrind
checks.  The fixes are specifically: failure to free global dir
path variables when not compiled with threading on and failure to
free filters from the filter registry that had not be initialized
fully.

There are a lot of places that we call git__free on each item in
a vector and then call git_vector_free on the vector itself.  This
just wraps that up into one convenient helper function.

This makes no functional change to diff but renames a couple of
the objects and splits the new git_patch (formerly git_diff_patch)
into a new header file.

This rolls back the changes to fnmatch parsing from commit
2e40a60e847d6c128af23e24ea7a8efebd2427da except for the tests
that were added.  Instead this adds couple of new flags that can
be passed in when attempting to parse an fnmatch pattern.  Also,
this changes the pathspec match logic to special case matching a
filename with a '!' prefix against a negative pattern.

This fixes the build.

status: fix handling of filenames with special prefixes

This adds an additional pathspec API that will match a pathspec
against a diff object.  This is convenient if you want to handle
renames (so you need the whole diff and can't use the pathspec
constraint built into the diff API) but still want to tell if the
diff had any files that matched the pathspec.

When the pathspec is matched against a diff, instead of keeping
a list of filenames that matched, instead the API keeps the list
of git_diff_deltas that matched and they can be retrieved via a
new API git_pathspec_match_list_diff_entry.

There are a couple of other minor API extensions here that were
mostly for the sake of convenience and to reduce dependencies
on knowing the internal data structure between files inside the
library.

This fixes the way the example log program decides if a merge
commit should be shown when a pathspec is given.  Also makes it
easier to use the pathspec API to just check "does a tree match
anything in the pathspec" without allocating a match list.

This adds a new public API for compiling pathspecs and matching
them against the working directory, the index, or a tree from the
repository.  This also reworks the pathspec internals to allow the
sharing of code between the existing internal usage of pathspec
matching and the new external API.

While this is working and the new API is ready for discussion, I
think there is still an incorrect behavior in which patterns are
always matched against the full path of an entry without taking
the subdirectories into account (so "s*" will match "subdir/file"
even though it wouldn't with core Git).  Further enhancements are
coming, but this was a good place to take a functional snapshot.

Right now, setting up a pathspec to be parsed and processed
requires several data structures and a couple of API calls.  This
adds a new high level data structure that contains all the items
that you'll need and high-level APIs that do all of the setup and
all of the teardown.  This will make it easier to use pathspecs
in various places with less repeated code.