config_file: fix quadratic behaviour when adding config multivars

In case where we add multiple configuration entries with the same key to
a diskfile backend, we always need to iterate the list of this key to
find the last entry due to the list being a singly-linked list. This
is obviously quadratic behaviour, and this has sure enough been found by
oss-fuzz by generating a configuration file with 50k lines, where most
of them have the same key. While the issue will not arise with "sane"
configuration files, an adversary may trigger it by providing a crafted
".gitmodules" file, which is delivered as part of the repo and also
parsed by the configuration parser.

The fix is trivial: store a pointer to the last entry of the list in its
head. As there are only two locations now where we append to this data
structure, mainting this pointer is trivial, too. We can also optimize
retrieval of a single value via `config_get`, where we previously had to
chase the `next` pointer to find the last entry that was added.

Using our configuration file fozzur with a corpus that has a single file
with 50000 "-=" lines previously took around 21s. With this optimization
the same file scans in about 0.053s, which is a nearly 400-fold
improvement. But in most cases with a "normal" amount of same-named keys
it's not going to matter anyway.

config: Fix a leak parsing multi-line config entries

Prevent heap-buffer-overflow

When running repack while doing repo writes, `packfile_load__cb()` can see some temporary files in the directory that are bigger than the usual, and makes `memcmp` overflow on the `p->pack_name` string. ASAN detected this. This just uses `strncmp`, that should not have any performance impact and is safe for comparing strings of different sizes.

```
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61200001a3f3 at pc 0x7f4a9e1976ec bp 0x7ffc1f80e100 sp 0x7ffc1f80d8b0
READ of size 89 at 0x61200001a3f3 thread T0
SCARINESS: 26 (multi-byte-read-heap-buffer-overflow)
    #0 0x7f4a9e1976eb in __interceptor_memcmp.part.78 (/build/cfgr-admin#link-tree/libtools_build_sanitizers_asan-ubsan-py.so+0xcf6eb)
    #1 0x7f4a518c5431 in packfile_load__cb /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb_pack.c:213
    #2 0x7f4a518d9582 in git_path_direach /build/libgit2/0.27.0/src/libgit2-0.27.0/src/path.c:1134
    #3 0x7f4a518c58ad in pack_backend__refresh /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb_pack.c:347
    #4 0x7f4a518c1b12 in git_odb_refresh /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:1511
    #5 0x7f4a518bff5f in git_odb__freshen /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:752
    #6 0x7f4a518c17d4 in git_odb_stream_finalize_write /build/libgit2/0.27.0/src/libgit2-0.27.0/src/odb.c:1415
    #7 0x7f4a51b9d015 in Repository_write /build/pygit2/0.27.0/src/pygit2-0.27.0/src/repository.c:509
```

ci: remove travis

The current error handling for the multiline variable parser is a bit
fragile, as each error condition has its own code to clear memory.
Instead, unify error handling as far as possible to avoid this
repetitive code. While at it, make use of `GITERR_CHECK_ALLOC` to
correctly handle OOM situations and verify that the buffer we print into
does not run out of memory either.

Update VSTS YAML files with the latest syntax

Documentation fixes

config: convert unbounded recursion into a loop

Document giterr_last() use only after error. #4772

util: make the qsort_r check work on macOS

fuzzer: update for indexer changes

tree: accept null ids in existing trees when updating

Pack file verification

This performs a compile-check by using CMake support, to differentiate the GNU
version from the BSD version of qsort_r.

Module taken from 4f252abea5f1d17c60f6ff115c9c44cc0b6f1df6, which I've checked
against CMake 2.8.11.

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.