Later on, we will move detection of required libraries, library
directories as well as include directories into a separate
CMakeLists.txt file inside of the source directory. Obviously, we want
to avoid duplication here regarding these parameters.

To prepare for the split, put the parameters into three variables
LIBGIT2_LIBS, LIBGIT2_LIBDIRS and LIBGIT2_INCLUDES, tracking the
required libraries, linking directory as well as include directories.
These variables can later be exported into the parent scope from inside
of the source build instructions, making them readily available for the
other subdirectories.

When refering to files and directories inside of the top-level "deps/"
directory, we're being inconsistent in using relative or absolute paths.
To enable splitting out parts of the top-level CMakeLists.txt into an
own file in the "src/" directory, consistently switch over to use
absolute paths to avoid errors when converting.

In our CMakeLists.txt, we have to check multiple functions in order to
determine if we have to use our own or whether we can use the
platform-provided one. For two of these functions, namely `regcomp_l()`
and `futimens`, the defined macro is actually used inside of the header
file "src/unix/posix.h". As such, these macros are not only required by
the library, but also by our test suite, which is makes use of internal
headers.

To prepare for the CMakeLists.txt split, move these two defines inside
of the "features.h" header.

In a future commit, we will split out the build instructions for our
library directory and move them into a subdirectory. One of the benefits
is fixing scoping issues, where e.g. defines do not leak to build
targets where they do not belong to. But unfortunately, this does also
pose the problem of how to propagate some defines which are required by
both the library and the test suite.

One way would be to create another variable keeping track of all added
defines and declare it inside of the parent scope. While this is the
most obvious and simplest way of going ahead, it is kind of unfortunate.
The main reason to not use this is that these defines become implicit
dependencies between the build targets. By simply observing a define
inside of the CMakeLists.txt file, one cannot reason whether this define
is only required by the current target or whether it is required by
different targets, as well.

Another approach would be to use an internal header file keeping track
of all defines shared between targets. While configuring the library, we
will set various variables and let CMake configure the file, adding or
removing defines based on what has been configured. Like this, one can
easily keep track of the current environment by simply inspecting the
header file. Furthermore, these dependencies are becoming clear inside
the CMakeLists.txt, as instead of simply adding a define, we now call
e.g. `SET(GIT_THREADSAFE 1)`.

Having this header file though requires us to make sure it is always
included before any "#ifdef"-preprocessor checks are executed. As we
have already refactored code to always include the "common.h" header
file before any statement inside of a file, this becomes easy: just make
sure "common.h" includes the new "features.h" header file first.

Our CMakeLists.txt is very unwieldy in its current size, spanning more
than 700 lines of code. Furthermore, it has several issues regarding
scoping, where for example some defines, includes, etc. from our test
suite are also applied to our normal library code.

To fix this, we can separate out build instructions for our tests and
move them into their own CMakeLists.txt in the "tests" directory. This
reduced complexity of the root CMakeLists.txt file and fixes the issues
regarding leaking build context from tests into the library.

As soon as we split up our CMakeBuild.txt build instructions, we will be
unable to simply link against the git2 library's precompiled header from
other targets. To avoid this future breakage, create a new precompiled
header for our test suite. Next to being compatible with the split, this
enables us to also include additional files like the clar headers, which
may help speeding up compilation of the test suite.

Currently, we're compiling our library code twice, once as part of the
libgit2 library and once for the libgit2_clar executable. Since CMake
2.8.8, there exists a new library type OBJECT, which represents an
intermediate target which can then subsequently be used when linking
several targets against the same set of objects.

Use an OBJECT library to create an internal library for linking. This
new target is only used on CMake v2.8.8 or newer. As CMake 3.0 changed
the way how generator expressions are evaluated when accessing
properties, we need to enable CMake policy 0051 to keep
`IDE_SPLIT_SOURCES` functioning.

Once upon a time, the `CLAR_RESOURCES` variable was intended to set
the `CLAR_RESOURCES` define. But actually, the define uses a wrong
variable name by accident, hinting that its value cannot actually be
used at all, as it is empty. Searching through the code base confirms
the guess that the define is not used at all.

Remove both the variable and definition.

While we already make use of the variable `${CMAKE_THREAD_LIBS_INIT}`,
it is actually undefined due to us never including the "FindThreads"
module in the CMakeLists.txt. It is rather curious as to why this has
never triggered any error up to now, but it does in fact result in
linking errors on some Unix platforms as soon as we split up our build
instructions into multiple files.

Fix the issue now to avoid future breakage by including the
"FindThreads" module.

Include fixups

Docs: Fix inline comments for git_diff_hunk

oid: use memcmp in git_oid__hashcmp

sha1_lookup: drop sha1_entry_pos function

sha1_position: convert do-while to while

The open-coded version was inherited from git.git. But it
turns out it was based on an older version of glibc, whose
memcmp was not very optimized.

Modern glibc does much better, and some compilers (like gcc
7) can even inline the memcmp into a series of multi-byte
xors.

Upstream is switching to using memcmp in
git/git@0b006014c87f400bd9a86267ed30fd3e7b383884.

This was pulled over from git.git, and is an experiment in
making binary-searching lists of sha1s faster. It was never
compiled by default (nor was it used upstream by default
without a special environment variable).

Unfortunately, it is actually slower in practice, and
upstream is planning to drop it in
git/git@f1068efefe6dd3beaa89484db5e2db730b094e0b (which has
some timing results). It's worth doing the same here for
simplicity.

If we enter the sha1_position() function with "lo == hi",
we have no elements. But the do-while loop means that we'll
enter the loop body once anyway, picking "mi" at that same
value and comparing nonsense to our desired key. This is
unlikely to match in practice, but we still shouldn't be
looking at the memory in the first place.

This bug is inherited from git.git; it was fixed there in
e01580cfe01526ec2c4eb4899f776a82ade7e0e1.

patch_generate: represent buffers as void pointers

Remove unused 'sys/remote.h' header

tests: rebase::submodule: verify initialization method calls

Some return codes for functions which may fail are not being checked in
`test_rebase_submodule__initialize`. This may lead us to not notice
errors when initializing the environment and would possibly result in
either memory corruption or segfaults as soon as any of the
initialization steps fails. Fix this by wrapping these function calls
into `cl_git_pass`.

tests: rewrite rebase-submodule .gitmodule file

tsort: remove idempotent conditional assignment

Build with patched libcurl

win32: provide fast-path for retrying filesystem operations

When using the `do_with_retries` macro for retrying filesystem
operations in the posix emulation layer, allow the remediation function
to return `GIT_RETRY`, meaning that the error was believed to be
remediated, and the operation should be retried immediately, without
a sleep.

This is a slightly more general solution to the problem fixed in #4312.

Fixed an issue where the retry logic on p_unlink sleeps before it tries setting a file to write mode causing unnecessary slowdown.

Ubuntu trusty has a bug in curl when using NTLM credentials in a proxy,
dereferencing a null pointer and causing segmentation faults.  Use a
custom-patched version of libcurl that avoids this issue.

The conditional `run < minrun` can never be true directly after
assigning `run = minrun`. Remove it to avoid confusion.

Fixes #4274

Configuration file fixes with includes