sha1: don't inline `git_hash_global_init` for win32

ignore: treat paths with trailing "/" as directories

The function `git_ignore_path_is_ignored` is there to test the
ignore status of paths that need not necessarily exist inside of
a repository. This has the implication that for a given path, we
cannot always decide whether it references a directory or a file,
and we need to distinguish those cases because ignore rules may
treat those differently. E.g. given the following gitignore file:

    *
    !/**/

we'd only want to unignore directories, while keeping files
ignored. But still, calling `git_ignore_path_is_ignored("dir/")`
will say that this directory is ignored because it treats "dir/"
as a file path.

As said, the `is_ignored` function cannot always decide whether
the given path is a file or directory, and thus it may produce
wrong results in some cases. While this is unfixable in the
general case, we can do better when we are being passed a path
name with a trailing path separator (e.g. "dir/") and always
treat them as directories.

Test that largefiles can be read through the tree API

Tests for symlinked user config

patch_parse: fix parsing addition/deletion of file with space

Optimize string comparisons

Users of the Win32 hash cannot be inlined, as it uses a static struct.
Don't inline it, but continue to declare the function in the header.

Negation of subdir ignore causes other subdirs to be unignored

According to reports, libgit2 is unable to read a global configuration
file that is simply a symlink to the real configuration. Write a
(succeeding) test that shows that libgit2 _is_ correctly able to do so.

While we do verify that we are able to open the global ".gitconfig" file
in config::global::open_global, we never verify that we it is in fact
readable. Do so by writing the global configuration file and verifying
that reading from it produces the expected values.

We've got reports that users are unable to open repos when their global
configuration ("~/.gitconfig") is a symlink. Add a test to verify that
we are in fact able to do so as expected.

Add a test that verifies that we are able to parse patches which add a
new file that has spaces in its path.

The diff header format is a strange beast in that it is inherently
unparseable in an unambiguous way. While parsing

    a/file.txt b/file.txt

is obvious and trivially doable, parsing a diff header of

    a/file b/file ab.txt b/file b/file ab.txt

is not (but in fact valid and created by git.git).

Due to that, we have relaxed our diff header parser in commit 80226b5f
(patch_parse: allow parsing ambiguous patch headers, 2017-09-22), so
that we started to bail out when seeing diff headers with spaces in
their file names. Instead, we try to use the "---" and "+++" lines,
which are unambiguous.

In some cases, though, we neither have a useable file name from the
header nor from the "---" or "+++" lines. This is the case when we have
a deletion or addition of a file with spaces: the header is unparseable
and the other lines will simply show "/dev/null". This trips our parsing
logic when we try to extract the prefix (the "a/" part) that is being
used in the path line, where we unconditionally try to dereference a
NULL pointer in such a scenario.

We can fix this by simply not trying to parse the prefix in cases where
we have no useable path name. That'd leave the parsed patch without
either `old_prefix` or `new_prefix` populated. But in fact such cases
are already handled by users of the patch object, which simply opt to
use the default prefixes in that case.

xdiff: fix typo

The config::global test suite creates various different directories and
files which are being populated with pretend-global files.
Unfortunately, the tests do not clean up after themselves, which may
cause subsequent tests to fail due to cruft left behind.

Fix this by always removing created directories and their contents.

docs: clarify relation of safe and forced checkout strategy

Each hash implementation should define `git_hash_global_init`

This means the forward declaration isn't necessary.  The forward
declaration can cause compilation errors as it conflicts with the
`GIT_INLINE` declaration (the signatures are different).

Matching on the prefix of a negated pattern was triggering false
negatives on siblings of that pattern. e.g.

Given the .gitignore:
dir/*
!dir/sub1/sub2/**

The path `dir/a.text` would not be ignored.

When a directory's contents are ignored, and then a glob negation is made to a nested subdir, other subdirectories are now unignored

[Doc] Update URL to git2-rs

remote: Rename git_remote_completion_type to _t

odb: provide a free function for custom backends

This reverts commit 1fe3fa5e.

For consistency with other "type" enums, rename
git_remote_completion_type to git_remote_completion_t.

Have git_branch_lookup accept GIT_BRANCH_ALL

Custom backends can allocate memory when reading objects and providing
them to libgit2.  However, if an error occurs in the custom backend
after the memory has been allocated for the custom object but before
it's returned to libgit2, the custom backend has no way to free that
memory and it must be leaked.

Provide a free function that corresponds to the alloc function so that
custom backends have an opportunity to free memory before they return an
error.