Update the global variables `LIBGIT2_OBJECTS` to
`LIBGIT2_DEPENDENCY_OBJECTS` for clarity and consistency.

Ensure that we always use lowercase function names, and that we do not
have spaces preceding open parentheses, for consistency.

Inside of our networking example code, we have a git2 executable
that acts as an entry point to all the different network
examples. As such, it is kind of the same like the normal git(1)
executable in that it simply arbitrates to the respective
subcommands.

Let's extend this approach and merge all examples into a single
standalone lg2 executable. Instead of building an executable
for all the existing examples we have, we now bundle them all
inside of the lg2 one and let them be callable via subcommands.

In the process, we can get rid of duplicated library
initialization, deinitialization and repository discovery code.
Instead of having each subcommand handle these on its own, we
simply do it inside of the single main function now.

Right now, we have two sets of "common" code, one containing
general common code and one containing network common code. As we
intend to get rid of the network subdirectory and instead merge
all examples into a single standalone executable, this
distinction doesn't make a lot of sense now. Furthermore, the
common network code is not that big.

Let's get rid of the common network code by merging it into the
general common code.

Although the error functions were deprecated, we did not properly mark
them as deprecated.  We need to include the `deprecated.h` file in order
to ensure that the functions get their export attributes.

Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or
those functions will also not get their export attributes.  Define that
only on the tests and examples.

While the aim of libgit2 was to conform to C90 code, we never instructed
the compiler to enforce C90 compliance. Thus, quite a few violations
were able to get into our code base, which have been removed with the
previous commits. As we are now able to build libgit2 with C90 enforced,
we can set the C_STANDARD property for our own build targets.

Note that we explicitly avoid setting the C standard for our third-party
dependencies. At least the zlib target does not build with C90 enforced,
and we do not want to fix them by deviating from upstream. Thus we
simply enforce no standard for them.

While we want to enforce strict C90 mode, this may cause issues with
system provided header files which are themselves not strictly
conforming. E.g. if a system header has C++ style comments, a compiler
in strict C90 mode would produce an error and abort the build. As the
user most likely doesn't want to change the system header, this would
completely break the build on such systems. One example of this is
mbedtls, which provides such header files.

The problem can be worked around by distinguishing between
system-provided and project-provided include directories. When adding
include directories via "-isystem" instead of "-I", the compiler will
skip certain checks and print out less warnings. To use system includes,
we can simply add the "SYSTEM" flag to CMake's `INCLUDE_DIRECTORIES` and
`TARGET_INCLUDE_DIRECTORIES` functions. Note that we have to split the
include directories into two variables because of this, as we definitely
still want to check for all warnings produced by our own header files.

With the recent change of always resolving pkg-config libraries to their
full path, we do not have to manage the LIBGIT2_LIBDIRS variable
anymore. The only other remaining user of LIBGIT2_LIBDIRS is winhttp,
which is a CMake-style library target and can thus be resolved by CMake
automatically.

Remove the variable to simplify our build system a bit.