Since ebabb88 (cmake: update minimum CMake version to v3.5.1,
2019-10-10), we have upgraded CMake to require at least v3.5.1. As the
command `CMAKE_MINIMUM_VERSION(VERSION 3.5.1)` implicitly calls
`CMAKE_POLICY(VERSION 3.5.1)`, all policies known until v3.5.1 get set
to the new behaviour automatically. As the newest policy we have been
setting to the new behaviour is policy 54, which was introduced in CMake
3.1, we can simply remove all our current calls to `CMAKE_POLICY`, as
they are enabled anyway.

The CMake module CheckPrototypeDefiniton has been introduced in CMake
v3.0, which is why we had to include a fallback copy of it in our own
modules in case somebody was compiling libgit2 with an older version of
CMake back when the minimum version was v2.8.11. As we have since raised
the minimum version to v3.5.1, we can now remove the module from our own
modules and simply always use the one provided by upstream.

All of our CMake modules are currently located in a directory
"cmake/Modules". It is not expected that there will ever be any CMake
files to distribute besides modules, which is why the "Modules"
intermediate directory is completely useless.

Move all modules directly into "cmake/".

Technically speaking, it is necessary to always set the minimum required
CMake version first before calling any other function in a CMake
project. Thus we should move the call to `CMAKE_MINIMUM_REQUIRED` before
the call to `PROJECT`, especially so as `PROJECT` may use features of
CMake which have been introduced with a certain version, only.

Currently, the project version is hidden inside of our "version.h"
header file and CMake extracts required information out of that file via
a regular expression. This is unwieldy and completely backwards, as it
should be the CMake file that sets the project's version and then puts
it into a configured file.

Move version information into the call to `PROJECT` and use
`CONFIGURE_FILE` to configure the "version.h.in" header. The configured
header will now be configured into a "include/git2/" directory together
with the "features.h" header and then finally gets installed into the
target directory. This also removes the awful hack of directly adding
our binary directory into the include paths, as there is now a
subdirectory "include" in our binary directory for configured headers.

While historic CMake code usually worked a lot with instructions that
modified global state, modern style works via targets. Thus instead of
first setting up the state before adding the actual target, which made
sense from a logical viewpoint with previous style, doesn't make a lot
of sense anymore for the new style. Instead, one would now typically
first declare the targets and then afterwards call functions to modify
these targets.

We're on the verge to migrate to this modern style of CMake. As a first
preparatory step, let's declare the library targets up front and set up
sources via `TARGET_SOURCES` instead of first gathering it in a global
variable. As this function has been introduced in CMake v3.1, we're good
to use it.

The previous commit already started by necessity to use `TARGET_SOURCES`
to set up the library's source files, as we started declaring the
library target up-front without any added sources yet. We can make our
easier to grasp though by going all-in with `TARGET_SOURCES`, thus
replacing use of all these variables like ${SRC_SSH} or ${SRC_SHA1} and
instead directly adding them in-place to the respective target. This not
only makes code easier to understand, but also makes sure that we cannot
forget to include any of these variables.

The libgit2 library has quite a lot of different dependencies that may
or may not be optional. Currently, the dependency handling code is a
_huge_ mess which nobody is able to grasp at all. Most of it is
currently done in the CMake build instructions of the source directory,
but they are split up to multiple locations, use global tracking via
weird variables and generally have been a source for confusion.

Modern CMake actually helps to sort out this mess by using targets all
the way through. Instead of manually tracking include directories, link
directories and flags, we can just set up a target for each dependency
that is completely self contained and has all information required to
link against it.

Introduce a new helper function `LINK_DEPENDENCY` that aims to help
migrating towards that target. The assumption is quite simple: for each
dependency, there will be a "cmake/DependencyFoo.cmake" file that gets
included by the helper. This dependency file is expected to _always_
export a target, even for dependencies which are not going to be used.
Thus, in the case where a dependency is found, the module should export
a normal target that contains linking and preprocessor information. In
the case where no dependency is found or in the case where it is not to
be used, the module is expected to export an empty target that simply
does nothing. Like this, every submodule can be completely
self-contained and we do not need to treat them specially in the main
build module.

Now that all of our dependencies have been migrated to use targets, we
do not need to set up include or link directories in any of our
dependents anymore. Instead, we just let them link against the
git2internal target, which includes all necessary information about
necessary build setup of itself and of its transitive dependencies. As
such, we can get rid of the respective instructions in our examples,
fuzzers and test code and also of the global lists LIBGIT2_OBJECTS,
LIBGIT2_INCLUDES, LIBGIT2_SYSTEM_INCLUDES and LIBGIT2_LIBS.

This is a final cleanup step that shifts around various bits in our
library's CMake build instruction to group them together in a logical
way.