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.

This change should now fix the issue for realsies.

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

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.

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
```

Use int64_t internally for type visibility.

When the patch contains lines close to INT_MAX, then it may happen that
we end up with an integer overflow when calculating the line of the
current diff hunk. Reject such patches as unreasonable to avoid the
integer overflow.

As the calculation is performed on integers, we introduce two new
helpers `git__add_int_overflow` and `git__sub_int_overflow` that perform
the integer overflow check in a generic way.

The commit list's in- and out-degrees are currently stored as `unsigned
short`. When assigning it the value of `git_array_size`, which returns
an `size_t`, this generates a warning on some Win32 platforms due to
loosing precision.

We could just cast the returned value of `git_array_size`, which would
work fine for 99.99% of all cases as commits typically have less than
2^16 parents. For crafted commits though we might end up with a wrong
value, and thus we should definitely check whether the array size
actually fits into the field.

To ease the check, let's convert the fields to store the degrees as
`uint16_t`. We shouldn't rely on such unspecific types anyway, as it may
lead to different behaviour across platforms. Furthermore, this commit
introduces a new `git__is_uint16` function to check whether it actually
fits -- if not, we return an error.

Correct the documentation on the fallback add/multiply with overflow
functions.

Windows provides <intsafe.h> which provides "performant" add and
multiply with overflow operations.  Use them when possible.