Fix the `-DENABLE_WERROR=ON` build for gcc 10.2

This change makes it possible to build with newer versions of gcc
without warnings. There were two warnings issued:

* gcc 8 added
  [`-Wstringop-truncation`](https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/),
  which warns if a call to `strncpy(3)` is prone to accidentally
  truncating the destination string, since `strncpy(3)` does NOT add a
  terminating `NULL` if the destination buffer is not large enough to
  hold the input.

  This change uses the pattern suggested in
  https://us-cert.cisa.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat
  to fix the locations flagged by gcc.
* There was a potentially uninitialized access of `dest` in `fs_copy`.

repository: use intptr_t's in the config map cache

Since we're using atomic primitives to read and write into the config
map cache, we need to read/write something pointer-sized.  Use an
`intptr_t` for the config map cache.

Add tests for `git__multiply_int64_overflow`

As it turns out, the implementation of `git__multiply_int64_overflow` is
full of edge cases and tricky arithmetic. That means that it should have
unit tests.

As a result, a bug in `git__strntol64` was found (and fixed!) in
clang+32-bit.

Third attempt to fix the 32-bit version of `git__multiply_int64_overf…

This change should now fix the issue for realsies.

`./libgit2_clar -score::strtol` passes on a 32-bit Docker.

Avoid using `__builtin_mul_overflow` with the clang+32-bit combo

This causes clang to produce an undefined reference to `__mulodi4`. This
could be fixed by statically linking some compiler-rt libraries to
provide this symbol, but let's first stop the bleeding since doing the
correct long-term fix requires some non-trivial CMake knowledge which I
lack.

ci: run codeql

pack: continue zlib while we can make progress

Continue the zlib stream as long as we can make progress; stop when we
stop getting output _or_ when zlib stops taking input from us.

Re-enable the RC4 test

Using RC4 is not a _certificate_ problem, it's a cipher problem.  The
SSL implementation should and will fail with an unrecoverable error
(-1).  There's no opportunity to accept/continue.

This used to fail with an error indicating a mis-use of OpenSSL on platforms
using it due to poor error handling. Re-enable it even if this isn't the right
error code to use for now.

Cache the parsed submodule config when diffing

Make git__strntol64() ~70%* faster

winhttp: support optional client cert

This change uses compiler intrinsics to detect overflows instead of
using divisions to detect potential overflow. This makes the code faster
and makes it easier to read as a bonus side-effect!

Some of the things this quickens:

* Config parsing.
* Tree parsing.
* Smart protocol negotiation.

\* Measured by running `libgit2_clar` with `-fno-optimize-sibling-calls
-fno-omit-frame-pointer` under `perf(1)`:

```shell
$ perf diff --symbols=git__strntol64 --compute=ratio \
  --percentage=absolute baseline.data perf.data
\# Event 'cycles'
\#
\# Baseline           Ratio  Shared Object
\# ........  ..............  .............
\#
     0.25%        0.321836  libgit2_clar
```

Also repurposed an unused function and deleted another one.

This change makes that anything that calls `git_diff__from_iterators`
(any of the `git_diff_xxx` functions) only need to parse the
`.gitmodules` file once. This can be avoided by calling
`git_repository_submodule_cache_all(...)`, but we can do that safely for
the user with no change in semantics.

Fixes: #5725

git.git-authors: Replacing his/her with their

Friendlier getting started in the lack of git_libgit2_init

We require the library to be initialized with git_libgit2_init before it
is functional.  However, if a user tries to uses the library without
doing so - as they might when getting started with the library for the
first time - we will likely crash.

This commit introduces some guard rails - now instead of having _no_
allocator by default, we'll have an allocator that always fails, and
never tries to set an error message (since the thread-local state is
set up by git_libgit2_init).  We've modified the error retrieval
function to (try to) ensure that the library has been initialized before
getting the thread-local error message.

(Unfortunately, we cannot determine if the thread local storage has
actually been configured, this does require initialization by
git_libgit2_init.  But a naive attempt should be good enough for most
cases.)

A function to provide the initialization count of the library; this is
subject to race conditions but is useful for a naive determination as to
whether the library has been initialized or not.

Thread-local storage: a generic internal library (with no allocations)

Use a no-allocation approach to the TLS data abstraction.

Provide more clarity for Win32 calling conventions - now that we always
compile to __cdecl on Win32, we'll define that as the the libgit2
calling convention.  Also offer NTAPI (__stdcall) calling conventions
for things that need callbacks from NTAPI code (eg fiber-local storage).

This adds a generic TLS interface for anyone to store TLS data. It is designed to work regardless of whether threading support is built into the library or not.

Nobody in the library should directly interface with the data on the TLS struct, so it's been built to be opaque even in the library.

Requires the allocator to be initialized before use.