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.

Use the smallest unsigned type that is equivalent to `size_t` to
simplify the conditionals.  Error if we're on a system that we believe
offers builtins but we cannot determine which one to use.

This change tweaks the macros for git__{add,multiply}_sizet_overflow so
that GCC can use them.

It also stops using the uadd,umul versions since the add,mul can handle
way more cases.

use consistent names for the #include / #define header guard pattern.