Fix GCC 8.1 warnings

Worktrees can be made from bare repositories

We were previously conflating any error into GIT_ENOTFOUND, which might
or might not be correct. This fixes the code so a config error is
bubbled up, as well as preserving the semantics in the face of
worktree-repositories

docs: add documentation to state differences from the git cli

Sanitize the hunk header to ensure it contains UTF-8 valid data

The diff driver truncates the hunk header text to 80 bytes, which can truncate
4-byte Unicode characters and introduce garbage characters in the diff
output. This change sanitizes the hunk header before it is displayed.

This mirrors the test in git: https://github.com/git/git/blob/master/t/t4025-hunk-header.sh

Closes https://github.com/libgit2/rugged/issues/716

examples: ls-files: add ls-files to list paths in the index

Since GCC 8.1, the compiler performs some bounds checking when
copying static data into arrays with a known size. In one test,
we print a format string of "%s/sub%02d" into a buffer of 64
bytes. The input buffer for the first "%s" is bounded to at most
63 characters, plus four bytes for the static string "/sub" plus
two more bytes for "%02d". Thus, our target buffer needs to be at
least 70 bytes in size, including the NUL byte. There seems to be
a bug in the analysis, though, because GCC will not account for
the limiting "%02" prefix, treating it as requiring the same
count of bytes as a "%d".

Thus, we end up at 79 bytes that are required to fix the
warning. To make it look nicer and less special, we just round
the buffer size up to 80 bytes.

Since version 8.1, GCC will do some automatic bounds checking
when printing static content into a buffer with known size. The
bounds checking doesn't yet work quite right in all scenarios and
may thus lead to false positives. Fix one of these false
positives in refs::normalize by simplifying the code.

Our provided callback function `threadid_cb(CRYPTO_THREADID
*threadid)` sets up a unique thread ID by asking pthread for the
current thread ID.  Since openssl version 1.1,
`CRYPTO_THREADID_set_numeric` is simply a no-op macro, leaving
the `threadid` argument unused after the preprocessor has
processed the macro. GCC does not account for that situation and
will thus complain about `threadid` being unused.

Silence this warning by using `GIT_UNUSED(threadid)`.

OpenSSL legacy API cleanups

This is the "OpenSSL available" global init function after all

worktree:  add functions to get name and path

Fix deletion of unrelated branch on worktree

mbedTLS support

Configuration entry iteration in order

blame_git: fix coalescing step never being executed

Fix leaks in master

Leak fixes for v0.27.1

worktree: Read worktree specific reflog for HEAD

Valgrind log:

==2711== 305 (48 direct, 257 indirect) bytes in 1 blocks are definitely lost in loss record 576 of 624
==2711==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2711==    by 0x5E079E: git__calloc (util.h:99)
==2711==    by 0x5E0D21: open_worktree_dir (worktree.c:134)
==2711==    by 0x5E0F23: git_worktree_lookup (worktree.c:176)
==2711==    by 0x5E1972: git_worktree_add (worktree.c:388)
==2711==    by 0x551F23: test_worktree_worktree__add_with_explicit_branch (worktree.c:292)
==2711==    by 0x45853E: clar_run_test (clar.c:222)
==2711==    by 0x4587E1: clar_run_suite (clar.c:286)
==2711==    by 0x458B04: clar_parse_args (clar.c:362)
==2711==    by 0x458CAB: clar_test_run (clar.c:428)
==2711==    by 0x45665C: main (main.c:24)

CID:1383993, "In git_refspec__dwim_one: All paths that lead to this null pointer comparison already dereference the pointer earlier (CWE-476)"

As per CID:1378747, we might be called with a NULL repo, which would be deferenced in write_add_refspec

Valgrind log :

==17702== 18 bytes in 1 blocks are indirectly lost in loss record 69 of 1,123
==17702==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17702==    by 0x5FDBB49: strdup (strdup.c:42)
==17702==    by 0x632B3E: git__strdup (util.h:106)
==17702==    by 0x632D2C: git_reference__alloc_symbolic (refs.c:64)
==17702==    by 0x62E0AF: loose_lookup (refdb_fs.c:408)
==17702==    by 0x62E636: refdb_fs_backend__iterator_next (refdb_fs.c:565)
==17702==    by 0x62CD8E: git_refdb_iterator_next (refdb.c:147)
==17702==    by 0x6347F2: git_reference_next (refs.c:838)
==17702==    by 0x6345CB: git_reference_foreach (refs.c:748)
==17702==    by 0x66BE62: local_download_pack (local.c:579)
==17702==    by 0x5DB48F: git_fetch_download_pack (fetch.c:148)
==17702==    by 0x639028: git_remote_download (remote.c:932)
==17702==    by 0x63919A: git_remote_fetch (remote.c:969)
==17702==    by 0x4ABEDD: test_fetchhead_nonetwork__fetch_into_repo_with_symrefs (nonetwork.c:362)
==17702==    by 0x4125D9: clar_run_test (clar.c:222)
==17702==    by 0x41287C: clar_run_suite (clar.c:286)
==17702==    by 0x412DDE: clar_test_run (clar.c:433)
==17702==    by 0x4105E1: main (main.c:24)

Signed-off-by: Sven Strickroth <email@cs-ware.de>

fixed stack smashing due to wrong size of struct stat on the stack

on 32-bit systems with 64-bit file descriptor offsets enabled
(added -D_FILE_OFFSET_BITS=64 when compiling the test suite)

scripts: add backporting script

worktree: add ability to create worktree with pre-existing branch

refs: preserve the owning refdb when duping reference

The CRLF data generator is somewhat obscure; add information about how
to use it and what it does.

Signed-off-by: Sven Strickroth <email@cs-ware.de>