Right now, there's quite a lot of different function calls to determine
whether a path component matches a specific name after normalization
from the filesystem. We have a function for each of {gitattributes,
gitmodules, gitignore} multiplicated with {generic, NTFS, HFS} checks.
In the long time, this is unmaintainable in case there are e.g. new
filesystems with specific semantics, blowing up the number of functions
we need to implement.

Replace all functions with a simple `git_path_is_gitfile` function,
which accepts an enum pointing out the filename that is to be checked
against as well as the filesystem normalizations to check for. This
greatly simplifies implementation at the expense of the caller having to
invoke a somewhat longer function call.

github: update issue template

streams: openssl: add missing check on OPENSSL_LEGACY_API

mbedtls: don't require mbedtls from our pkgconfig file

The `CRYPTO_THREADID` type is no longer available in OpenSSL ≥ 1.1.0 with deprecated features disabled, and causes build failures. Since the `threadid_cb()` function is only ever called by `git_openssl_set_locking()` when `defined(OPENSSL_LEGACY_API)`, only define it then.

Fixes for CVE 2018-11235

mbedTLS has no pkgconfig file, hence we can't require it. For now, pass its link flags as our own.

Added note about Windows junction points to the differences from git document

We might modify caches due to us trying to load the configuration to figure out
what kinds of filesystem protections we should have.

We still compare case-insensitively to protect more thoroughly as we don't know
what specifics we'll see on the system and it's the behaviour from git.

When dealing with `core.proectNTFS` and `core.protectHFS` we do check
against `.gitmodules` but we still have a failing test as the non-filesystem
codepath does not check for it.

Any part of the library which asks the question can pass in the mode to have it
checked against `.gitmodules` being a symlink.

This is particularly relevant for adding entries to the index from the worktree
and for checking out files.

This is so we have it available for the path validity checking. In a later
commit we will start rejecting `.gitmodules` files as symlinks.

We may take in names from the middle of a string so we want the caller to let us
know how long the path component is that we should be checking.

We want to reject these as they cause compatibility issues and can lead to git
writing to files outside of the repository.

These will be used by the checkout code to detect them for the particular
filesystem they're on.

These can't go into the public API yet as we don't want to introduce API or ABI
changes in a security release.

Given a path component it knows what to pass to the filesystem-specific
functions so we're protected even from trees which try to use the 8.3 naming
rules to get around us matching on the filename exactly.

The logic and test strings come from the equivalent git change.

It checks against the 8.3 shortname variants, including the one which includes
the checksum as part of its name.

This lets us check for other kinds of reserved files.

Otherwise we would also admit `..\..\foo\bar` as a valid path and fail to
protect Windows users.

Ideally we would check for both separators without the need for the copied
string, but this'll get us over the RCE.

If the we decide that the "name" of the submodule (i.e. its path inside
`.git/modules/`) is trying to escape that directory or otherwise trick us, we
ignore the configuration for that submodule.

This leaves us with a half-configured submodule when looking it up by path, but
it's the same result as if the configuration really were missing.

The name check is potentially more strict than it needs to be, but it lets us
re-use the check we're doing for the checkout. The function that encapsulates
this logic is ready to be exported but we don't want to do that in a security
release so it remains internal for now.

cmake: resolve libraries found by pkg-config 

refdb_fs: enhance performance of globbing

global: adjust init count under lock

Fix GCC 8.1 warnings

With the recent change of always resolving pkg-config libraries to their
full path, we do not have to manage the LIBGIT2_LIBDIRS variable
anymore. The only other remaining user of LIBGIT2_LIBDIRS is winhttp,
which is a CMake-style library target and can thus be resolved by CMake
automatically.

Remove the variable to simplify our build system a bit.

Libraries found by CMake modules are usually handled with their full
path. This makes linking against those libraries a lot more robust when
it comes to libraries in non-standard locations, as otherwise we might
mix up libraries from different locations when link directories are
given.

One excemption are libraries found by PKG_CHECK_MODULES. Instead of
returning libraries with their complete path, it will return the
variable names as well as a set of link directories. In case where
multiple sets of the same library are installed in different locations,
this can lead the compiler to link against the wrong libraries in the
end, when link directories of other dependencies are added.

To fix this shortcoming, we need to manually resolve library paths
returned by CMake against their respective library directories. This is
an easy task to do with `FIND_LIBRARY`.

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