When we transform a refspec with a component containing a glob, then
we simply copy over the component until the next separator from
the matching ref. E.g. if we have a ref "refs/heads/foo/bar" and
a refspec "refs/heads/*/bar:refs/remotes/origin/*/bar", we:

1. Copy over everything until hitting the glob from the <dst>
   part: "refs/remotes/origin/".
2. Strip the common prefix of ref and <src> part until the glob,
   which is "refs/heads/". This leaves us with a ref of "foo/bar".
3. Copy from the ref until the next "/" separator, resulting in
   "refs/remotes/origin/foo".
4. Copy over the remaining part of the <dst> spec, which is
   "bar": "refs/remotes/origin/foo/bar".

This worked just fine in a world where globs in refspecs were
restricted such that a globbing component may only contain a
single "*", only. But this restriction has been lifted, so that a
glob component may be nested between other characters, causing
the above algorithm to fail. Most notably the third step, where
we copy until hitting the next "/" separator, might result in a
wrong transformation. Given e.g. a ref "refs/gbranchg/head" and a
refspec "refs/g*g/head:refs/remotes/origin/*", we'd also be
copying the "g" between "branch" and "/" and end up with the
wrong transformed ref "refs/remotes/origin/branchg".

Instead of copying until the next component separator, we should
copy until we hit the pattern after the "*". So in the above
example, we'd copy until hitting the string "g/head".

In commit cd377f45c9 (refs: loosen restriction on wildcard "*"
refspecs, 2015-07-22) in git.git, the restrictions on wildcard
"*" refspecs has been loosened. While wildcards were previously
only allowed if the component is a single "*", this was changed
to also accept other patterns as part of the component.

We never adapted to that change and still reject any wildcard
patterns that aren't a single "*" only. Update our tests to
reflect the upstream change and adjust our own code accordingly.

git_repository_init: stop traversing at windows root

Stop traversing the filesystem at the Windows directory root.  We were
calculating the filesystem root for the given directory to create, and
walking up the filesystem hierarchy.  We intended to stop when the
traversal path length is equal to the root path length (ie, stopping at
the root, since no path may be shorter than the root path).

However, on Windows, the root path may be specified in two different
ways, as either `Z:` or `Z:\`, where `Z:` is the current drive letter.
`git_path_dirname_r` returns the path _without_ a trailing slash, even
for the Windows root.  As a result, during traversal, we need to test
that the traversal path is _less than or equal to_ the root path length
to determine if we've hit the root to ensure that we stop when our
traversal path is `Z:` and our calculated root path was `Z:\`.

config_file: check result of git_array_alloc

git_array_alloc can return NULL if no memory is available, causing
a segmentation fault in memset. This adds GIT_ERROR_CHECK_ALLOC
similar to how other parts of the code base deal with the return
value of git_array_alloc.

patch_parse.c: Handle CRLF in parse_header_start

fix typo

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