worktree: unlock should return 1 when the worktree isn't locked

Add a fuzzer for config files

Fix 'invalid packet line' for ng packets containing errors

Fix leak in index.c

threads::diff: use separate git_repository objects

Our thread policies state that we cannot re-use the `git_repository`
across threads.  Our tests cannot deviate from that.

Courtesy of Ximin Luo, https://github.com/infinity0:

https://github.com/libgit2/libgit2/issues/4753#issuecomment-412247757

travis: remove Coverity cron job

The documentation states that git_worktree_unlock returns 0 on success,
and 1 on success if the worktree wasn't locked. Turns out we were
returning 0 in any of those cases.

parse: Do not initialize the content in context to NULL

config_file: Don't crash on options without a section

With the recent addition of VSTS to our CI infrastructure, we now have
two cron jobs running regular Coverity analysis. It doesn't really make
a lot of sense to upload two different analysis on our sources to
Corverity, though:

- in the worst case, Coverity will be repeatedly confused when different
  sets of sources get analyzed and uploaded
- in the best case, nothing is gained because the sources have already
  been analyzed via the other job

Let's just use a single cron job for Coverity. Considering that VSTS
seems to be the more beefy and flexible platform, it is more likely to
be our future target CI platform. Thus, we retain its support for
Coverity and instead remove it from Travis.

ci: Correct the status code check so Coverity doesn't force-fail Travis

Otherwise you get something like

Emitted 525 C/C++ compilation units (100%) successfully

525 C/C++ compilation units (100%) are ready for analysis
The cov-build utility completed successfully.
Build successfully submitted.
Received error code 200 from Coverity

travis_time:end:14cf6373:start=1534254309066933889,finish=1534254728190974302,duration=419124040413
The command "if [ -n "$COVERITY" ]; then ../ci/coverity.sh; fi" exited with 1.
travis_time:start:01ed61d4
$ if [ -z "$COVERITY" ]; then ../ci/build.sh && ../ci/test.sh; fi

travis_time:end:01ed61d4:start=1534254728197560961,finish=1534254728202711214,duration=5150253
The command "if [ -z "$COVERITY" ]; then ../ci/build.sh && ../ci/test.sh; fi" exited with 0.

Done. Your build exited with 1.

ci: remove appveyor

diff: fix OOM on AIX when finding similar deltas in empty diff

The function `git_diff_find_similar` keeps a function of cache
similarity metrics signatures, whose size depends on the number of
deltas passed in via the `diff` parameter. In case where the diff is
empty and thus doesn't have any deltas at all, we may end up allocating
this cache via a call to `git__calloc(0, sizeof(void *))`. At least on
AIX, allocating 0 bytes will result in a `NULL` pointer being returned,
which causes us to erroneously return an OOM error.

Fix this situation by simply returning early in case where we are being
passed an empty diff, as we cannot find any similarities in that case
anyway.

travis: do not execute Coverity analysis for all cron jobs

ci: enable compilation with "-Werror"

smart_pkt: fix potential OOB-read when processing ng packet

During the conversion of our CI scripts in bf418f09 (ci: refactor unix
ci build/test scripts, 2018-07-14), we accidentally dropped the
"-DENABLE_WERROR=ON" switch in our cmake invocation. Re-add it to help
us catch compiler warnings early.

The `git_odb_stream` members `declared_size` and `received_bytes` are
both of the type `git_off_t`, which we usually defined to be a 64 bit
signed integer. Thus, passing these members to "PRIdZ" formatters is not
correct, as they are not guaranteed to accept big enough numbers.
Instead, use the "PRId64" formatter, which is able to represent 64 bit
signed integers.

Fix a double-free in config parsing

The new Travis cron job gets executed daily, but our current
configuration will cause each job to execute our Coverity script instead
of the default build and testing scripts. This cannot work, as Coverity
is heavily rate-limiting its API, so our cron builds are doomed to
always fail. What we want to do instead is execute our normal builds,
but add an additional Coverity jobs.

This can easily be done by adding another Coverity-specific job with a
conditional "type = cron", which sets the "COVERITY" environment
variable. Instead of checking the build type, we then simply check
whether "COVERITY" is set or not.

Our thread policies state that we cannot re-use the `git_repository`
across threads.  Our tests cannot deviate from that.