When we are provided some input buffer (with a length) to inflate,
and it contains more data than simply the deflated data, fail.
zlib will helpfully tell us when it is done reading (via Z_STREAM_END),
so if there is data leftover in the input buffer, fail lest we
continually try to inflate it.

Handle the application of binary patches.  Include tests that
produce a binary patch (an in-memory `git_patch` object),
then enusre that the patch applies correctly.

Introduce `git_zstream_inflatebuf` for simple uses.

Refactor the git_delta functions to have consistent naming and
parameters with the rest of the library.

Move the delta application functions into `delta.c`, next to the
similar delta creation functions.  Make the `git__delta_apply`
functions adhere to other naming and parameter style within the
library.

When a patch is empty, simply copy the source into the destination.

The beginnings of patch application from an existing (diff-created)
git_patch object: applies the hunks of a git_patch to a buffer.

Use AppVeyor's Start-FileDownload cmdlet

test: Fix stat() test to mask out unwanted bits

Don't generate conflicts when checking out a modified submodule and the
submodule is dirty or modified in the workdir.

Fix comment for GIT_FILEMODE_LINK

Start-FileDownload maintains current directory context and allows
specifying a request timeout, see [1].

[1] https://www.appveyor.com/docs/how-to/download-file#start-filedownload-cmdlet

Haiku and Hurd both pass extra bits in struct stat::st_mode.

tree: handle removal of all entries in the updater

When we remove all entries in a tree, we should remove that tree from
its parent rather than include the empty tree.

Tree updater fixups

When we want to remove the file, use the basename as the name of the
entry to remove, instead of the full one, which includes the directories
we've inserted into the stack.

This gives us trees with subdirectories, which the new test needs.

0120000 is symbolic link, not commit

Add a method specifically for modifying trees

Instead of going through the usual steps of reading a tree recursively
into an index, modifying it and writing it back out as a tree, introduce
a function to perform simple updates more efficiently.

`git_tree_create_updated` avoids reading trees which are not modified
and supports upsert and delete operations. It is not as versatile as
modifying the index, but it makes some common operations much more
efficient.

Misc fixes

Fix unused variable 'message' warning

Fix `git_commit_create` for an initial commit

`test_commit_commit__create_initial_commit_parent_not_current` was not correctly 
testing that `HEAD` was not changed. Now we grab the oid that it was pointing to
before the call to `git_commit_create` and the oid that it's pointing to afterwards
and compare those.

Rebase: rebase a branch with no merge base for in-memory

When calling `git_commit_create` with an empty array of `parents` and `parent_count == 0` 
the call will segfault at https://github.com/libgit2/libgit2/blob/master/src/commit.c#L107 
when it's trying to compare `current_id` to a null parent oid. 

This just puts in a check to stop that segfault.

When determining diffs between two iterators we may need to
recurse into an unmatched directory for the "new" iterator when
it is either a prefix to the current item of the "old" iterator
or when untracked/ignored changes are requested by the user and
the directory is untracked/ignored.

When advancing into the directory and no files are found, we will
get back `GIT_ENOTFOUND`. If so, we simply skip the directory,
handling resulting unmatched old items in the next iteration. The
other case of `iterator_advance_into` returning either
`GIT_NOERROR` or any other error but `GIT_ENOTFOUND` will be
handled by the caller, which will now either compare the first
directory entry of the "new" iterator in case of `GIT_ENOERROR`
or abort on other cases.

Improve readability of the code to make the above logic more
clear.

odb: avoid inflating the full delta to read the header

We compute offsets by executing `off |= (*delta++ << 24)` for
multiple constants, where `off` is of type `size_t` and `delta`
is of type `unsigned char`. The usual arithmetic conversions (see
ISO C89 §3.2.1.5 "Usual arithmetic conversions") kick in here,
causing us to promote both operands to `int` and then extending
the result to an `unsigned long` when OR'ing it with `off`.
The integer promotion to `int` may result in wrong size
calculations for big values.

Fix the issue by making the constants `unsigned long`, causing both
operands to be promoted to `unsigned long`.