Implement plain username credential types. These type of
credentials might be asked for e.g. as some kind of
pre-authentication step, before the actual credentials are
passed.

Credential callback are being passed a bitset that indicates
which credential types are allowed in the current context. In our
examples code, we completely ignore that field and always return
username/password credentials, which doesn't necessarily make
sense e.g. when only SSH keys are allowed.

Refactor the code and only return username/password credentials
in the case where `USERPASS_PLAINTEXT` credentials are allowed.
Otherwise, return a positive error code to indicate that no
credentials could be acquired.

We currently have two locations in our examples where we define
the same compatibility wrappers for MSVC. Move them into
"common.h" to avoid duplication and make them available to other
examples.

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

remote: Rename git_remote_completion_type to _t

odb: provide a free function for custom backends

This reverts commit 1fe3fa5e.