patch_parse: fix parsing addition/deletion of file with space

Optimize string comparisons

Negation of subdir ignore causes other subdirs to be unignored

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

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.

The `git_odb_backend_malloc` name is a system function that is provided
for custom ODB backends and allows them to allocate memory for an ODB
object in the read callback.  This is important so that libgit2 can
later free the memory used by an ODB object that was read from the
custom backend.

However, the name _suggests_ that it actually allocates a
`git_odb_backend`.  It does not; rename it to make it clear that it
actually allocates backend _data_.

Rename git_transfer_progress to git_indexer_progress

Safely deprecate `git_push_transfer_progress`, forwarding it to the new
`git_push_transfer_progress_cb` name.

The `git_push_transfer_progress` is a callback and as such should be
suffixed with `_cb` for consistency.  Rename
`git_push_transfer_progress` to `git_push_transfer_progress_cb`.

Safely deprecate `git_transfer_progress` and `git_transfer_progress_cb`
types, forwarding them to the new `git_indexer_progress` and
`git_indexer_progress_cb`.

Update internal usage of `git_transfer_progress` to
`git_indexer_progreses`.

The name `git_transfer_progress` does not reflect its true purpose.

It suggests that it's progress for a non-existence `git_transfer`
object, and is used for indexing callbacks more broadly than just
during transfers.

Rename `git_transfer_progress` to `git_indexer_progress`.

High-level map APIs

refdb_fs: fix loose/packed refs lookup racing with repacks