cmake: detect and use libc-provided iconv

Coverity flavored clang analyzer fixes

tests: verify adding index conflicts with invalid filemodes fails

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

While most systems provide a separate iconv library against which
applications can link, musl based systems do not provide such a library.
Instead, iconv functions are directly included in the C library. As our
current CMake module to locate the iconv library only checks whether a
library exists somewhere in the typical library directories, we will
never build libgit2 with libiconv support on such systems.

Extend the iconv module to also search whether libc provides iconv
functions, which we do by checking whether the `iconv_open` function
exists inside of libc. If this is the case, we will default to use the
libc provided one instead of trying to use a separate libiconv. While
this changes which iconv we use on systems where both libc and an
external libiconv exist, to the best of my knowledge common systems only
provide either one or the other.

Note that libiconv support in musl is held kind of basic. To quote musl
libc's page on functional differences from glibc [1]:

    The iconv implementation musl is very small and oriented towards
    being unobtrusive to static link. Its character set/encoding
    coverage is very strong for its size, but not comprehensive like
    glibc’s.

As we assume iconv to be a lot more capable than what musl provides,
some of our tests will fail if using iconv on musl-based platforms.

[1]: https://wiki.musl-libc.org/functional-differences-from-glibc.html

Add a fuzzer for config files

Commit 581d5492 (Fix leak in index.c, 2018-08-16) was fixing a memory
leak in our code adding conflicts to the index when the added index
entries have an invalid file mode. The memory leak was previously
undiscovered as there are no tests covering this scenario, which is now
being added by this commit.

Fix 'invalid packet line' for ng packets containing errors

Otherwise we return a NULL context, which will get dereferenced in 
apply_credentials.

Otherwise we'll return stack data to the caller.

In case there was nothing to parse in the buf, we'd return uninitialized
stack data.

At line 594, we do this :
if (error < 0)
		return error;

but if nothing was pushed in a GIT_SORT_TIME revwalk, we'd return
uninitialized stack data.

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