s/Init/Index comment tweak for test_repo_init__init_with_initial_commit

signature: distinguish +0000 and -0000 UTC offsets

Git considers '-0000' a valid offset for signature lines.  They need to
be treated as _not_ equal to a '+0000' signature offset.  Parsing a
signature line stores the offset in a signed integer which does not
distinguish between `+0` and `-0`.

This patch adds an additional flag `sign` to the `git_time` in the
`signature` object which is populated with the sign of the offset.  In
addition to exposing this information to the user, this information is
also used to compare signatures.

/cc @pks-t @ethomson

Fix clar to verify command line arguments before execute

Common parser interface

When executing `libgit2_clar -smerge -invalid_option`, it will first execute
the merge test suite and afterwards output help because of the invalid option.

With this changa, it verifies all options before execute. If there are any
invalid options, it will output help and exit without actually executing
the test suites.

cmake: Allow user to select bundled zlib

As the config parser is now cleanly separated from the config file code,
we can easily refactor the code and make use of the common parser
module. This removes quite a lot of duplicated functionality previously
used for handling the actual parser state and replaces it with the
generic interface provided by the parser context.

The configuration file code grew quite big and intermingles both actual
configuration logic as well as the parsing logic of the configuration
syntax. This makes it hard to refactor the parsing logic on its own and
convert it to make use of our new parsing context module.

Refactor the code and split it up into two parts. The config file code
will only handle actual handling of configuration files, includes and
writing new files. The newly created config parser module is then only
responsible for parsing the actual contents of a configuration file,
leaving everything else to callbacks provided to its provided function
`git_config_parse`.

Upon initializing the parser context, we do not currently initialize the
current line, line length and line number. Do so in order to make the
interface easier to use and more obvious for future consumers of the
parsing API.

Some code parts need to inspect the next few bytes without actually
consuming it yet, for example to examine what content it has to expect
next. Create a new function `git_parse_peek` which returns the next byte
without modifying the parsing context and use it at multiple call sites.

The patch parsing code has multiple recurring patterns where we want to
parse an actual number. Create a new function `git_parse_advance_digit`
and use it to avoid code duplication.

Instead of manually checking the parsing context's remaining length and
comparing the leading bytes with a specific string, we can simply re-use
the function `git_parse_ctx_contains_s`. Do so to avoid code duplication
and to further decouple patch parsing from the parsing context's struct
members.

The `git_patch_parse_ctx` encapsulates both parser state as well as
options specific to patch parsing. To advance this state and keep it
consistent, we provide a few functions which handle advancing the
current position and accessing bytes of the patch contents. In fact,
these functions are quite generic and not related to patch-parsing by
themselves. Seeing that we have similar logic inside of other modules,
it becomes quite enticing to extract this functionality into its own
parser module.

To do so, we create a new module `parse` with a central struct called
`git_parse_ctx`. It encapsulates both the content that is to be parsed
as well as its lengths and the current position. `git_patch_parse_ctx`
now only contains this `parse_ctx` only, which is then accessed whenever
we need to touch the current parser. This is the first step towards
re-using this functionality across other modules which require parsing
functionality and remove code-duplication.

Under some circumstances the installed / system version of zlib may not
be desirable due to being too old or buggy.  This patch adds the option
`USE_BUNDLED_ZLIB` that will cause the bundled version of zlib to be
used.

We may also want to add similar functionality to allow the user to
select other bundled 3rd-party dependencies instead of using the system
versions.

/cc @pks-t @ethomson

patch_parse: implement state machine for parsing patch headers

describe.h: fix spelling in comments

optios -> options

CMake: make HTTPS support more generic

travis: put clar's sandbox in a ramdisk on macOS

appveyor: build examples

The getline(3) function call is not part of ISO C and, most importantly,
it is not implemented on Microsoft Windows platforms. As our networking
example code makes use of getline, this breaks builds on MSVC and MinGW.
As this code wasn't built prior to the previous commit, this was never
noticed.

Fix the error by instead implementing a `readline` function, which
simply reads the password from stdin until it reads a newline
character.

By default, CMake will not build our examples directory. As we do not
instruct either the MinGW or MSVC builds on AppVeyor to enable building
these examples, we cannot verify that those examples at least build on
Windows systems.

Fix that by passing `-DBUILD_EXAMPLES=ON` to AppVeyor's CMake
invocation.

ignore spaces in .gitignore files

Conditional includes

The macOS tests are by far the slowest right now. This attempts to remedy the
situation somewhat by asking clar to put its test data on a ramdisk.

We put our repository in the temporary directory which makes macOS map the path
into a virtual path. `realpath(3)` can resolve it and we do so during repository
opening, but that makes its path have a different prefix from the sandbox path
clar thinks we have.

Resolve the sandbox path before putting it into the test config files so the
paths match as expected.

travis: grab pgp key from www.edwardthomson.com

Preserve the input casing when writing config files

Getting the key from the MIT keyserver is surprisingly unreliable.
Try getting it from my website instead...

For sections we will still use the existing one even if the case disagrees, but
the variable always gets written with the case given by the caller.

While most parts of a configuration key are case-insensitive, we should still be
case-preserving and write down whatever string the caller provided.