When we do not trust the on-disk mode, we use the mode of an existing
index entry.  This allows us to preserve executable bits on platforms
that do not honor them on the filesystem.

If there is no stage 0 index entry, also look at conflicts to attempt
to answer this question:  prefer the data from the 'ours' side, then
the 'theirs' side before falling back to the common ancestor.

net: add tests against badssl.com

These provide bad X.509 certificates, which we should refuse to connect
to by default.

Fix binary diffs

git expects an empty line after the binary data:

literal X
...binary data...
<empty_line>

The last literal block of the generated patches were not containing the required empty line. Example:

	diff --git a/binary_file b/binary_file
	index 3f1b3f9098131cfecea4a50ff8afab349ea66d22..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
	GIT binary patch
	literal 8
	Pc${NM&PdElPvrst3ey5{

	literal 6
	Nc${NM%g@i}0ssZ|0lokL
	diff --git a/binary_file2 b/binary_file2
	index 31be99be19470da4af5b28b21e27896a2f2f9ee2..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
	GIT binary patch
	literal 8
	Pc${NM&PdElPvrst3ey5{

	literal 13
	Sc${NMEKbZyOexL+Qd|HZV+4u-

git apply of that diff results in:

	error: corrupt binary patch at line 9: diff --git a/binary_file2 b/binary_file2
	fatal: patch with only garbage at line 10

The proper formating is:

	diff --git a/binary_file b/binary_file
	index 3f1b3f9098131cfecea4a50ff8afab349ea66d22..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
	GIT binary patch
	literal 8
	Pc${NM&PdElPvrst3ey5{

	literal 6
	Nc${NM%g@i}0ssZ|0lokL
	diff --git a/binary_file2 b/binary_file2
	index 31be99be19470da4af5b28b21e27896a2f2f9ee2..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644
	GIT binary patch
	literal 8
	Pc${NM&PdElPvrst3ey5{

	literal 13
	Sc${NMEKbZyOexL+Qd|HZV+4u-

submodule: plug a few leaks

win32: give better error message on long paths

Win32 Reserved names: don't reserve names outside the working directory

Keep config comments in the same place as git

Check that the repository directory is beneath the workdir before
adding it to the list of reserved paths.  If it is not, then there
is no possibility of checking out files into it, and it should not
be a reserved word.

This is a particular problem with submodules where the repo directory
may be in the super's .git directory.

Test an initial submodule update, where we are trying to checkout
the submodule for the first time, and placing a file within the
submodule working directory with the same name as the submodule
(and consequently, the same name as the repository itself).

When there is a comment at the end of a section, git keeps it there,
while we write the new variable right at the end.

Keep comments buffered and dump them when we're going to output a
variable or section, or reach EOF. This puts us in line with the config
files which git produces.

pkg-config: fix directory references in libgit2.pc

Before:
libdir=/usr//usr/lib64
includedir=/usr//usr/include

After:
libdir=/usr/lib64
includedir=/usr/include

(note the duplication of /usr in the before case)

`mkdir`: split into `mkdir` and `mkdir_relative`

Don't coalesce all errors into ENOENT.  At least identify EACCES.
All callers should be handling this case already, as the POSIX
`lstat` will return this.

`git_futils_mkdir` does not blindly call `git_futils_mkdir_relative`.

`git_futils_mkdir_relative` is used when you have some base directory
and want to create some path inside of it, potentially removing blocking
symlinks and files in the process.  This is not suitable for a general
recursive mkdir within the filesystem.

Instead, when `mkdir` is being recursive, locate the first existent
parent directory and use that as the base for `mkdir_relative`.

In `mkdir` and `mkdir_r`, ensure that we don't try to remove symlinks
that are in our way.

Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter
assumes that we own everything beneath the base, as if it were
being called with a base of the repository or working directory,
and is tailored towards checkout and ensuring that there is no
bogosity beneath the base that must be cleaned up.

This is (at best) slow and (at worst) unsafe in the larger context
of a filesystem where we do not own things and cannot do things like
unlink symlinks that are in our way.

Checkout: handle mode changes

When a file exists on disk and we're checking out a file that differs
in executableness, remove the old file.  This allows us to recreate the
new file with p_open, which will take the new mode into account and
handle setting the umask properly.

Remove any notion of chmod'ing existing files, since it is now handled
by the aforementioned removal and was incorrect, as it did not take
umask into account.

Clone test buffer

Handle `git_path_diriter` instances at the drive root on Windows

iterator: loop fs_iterator advance (don't recurse)