ci: build with ENABLE_WERROR on Windows

The function `git_win32__stack__set_aux_cb` expects the second parameter
to be a function callback of type `git_win32__stack__aux_cb_lookup`,
which expects a `size_t` parameter. In our test suite
trace::windows::stacktrace, we declare the callback with `unsigned int`
as parameter, though, causing a compiler warning.

Correct the parameter type to silence the warning.

In both `git_win32__stack_format` and `git_win32__stack`, we handle
buffer lengths via an integer variable. As we only ever pass buffer
sizes to it, this should be a `size_t` though to avoid loss of
precision. As we also use it to compare with other `size_t` variables,
this also silences signed/unsigned comparison warnings.

We use the `__LINE__` macro in several places throughout clar to allow
easier traceability when e.g. a test fails. While `__LINE__` is of type
`size_t`, the clar functions all accept an integer and thus may loose
precision. While unlikely that any file in our codebase will exceed a
linecount of `INT_MAX`, let's convert it anyway to silence any compiler
warnings.

When iterating over index entries, we store the indices in an unsigned
int. As the index entrycount is a `size_t` though, this may be a loss of
precision which a compiler might rightfully complain about.

Use `size_t` instead to fix any warnings.

When computing the progress, we perform some arithmetics that are
implicitly converting from `size_t` to `int`. In one case we're
calclulating a percentage, so we know that it should always be in the
range of [0,100] and thus we're fine. In the other case we convert from
bytes to kilobytes -- this should be stored in a `size_t` to avoid loss
of precision, even though it probably won't matter due to limited
download rates.

The memchr(3P) function expects a `size_t` as its last parameter, but we
do pass it an object size, which is of signed type `git_off_t`. As we
can be sure that the result will be non-negative, let's just cast the
parameter to a `size_t`.

When reallocating commit arrays in `opts_add_commit` and
`opts_add_refish`, respectively, we simply pass the const pointer to
`xrealloc`. As `xrealloc` expects a non-const pointer, though, this will
generate a warning with some compilers.

Cast away the constness to silence compilers.

Fix Regression: attr: Correctly load system attr file (on Windows)

There were no tests that verified that system-level gitattributes files
get handled correctly. In fact, we have recently introduced a regression
that caused us to abort if there was a system-level gitattributes file
available.

Add two tests that verify that we're able to handle system-level
gitattributes files. The test attr::repo::sysdir_with_session would've
failed without the fix to the described regression.

The function `git_attr_session__init` is currently only initializing
setting up the attribute's session key by incrementing the repo-global
key by one. Most notably, all other members of the `git_attr_session`
struct are not getting initialized at all. So if one is to allocate a
session on the stack and then calls `git_attr_session__init`, the
session will still not be fully initialized. We have fared just fine
with that until now as all users of the function have allocated the
session structure as part of bigger structs with `calloc`, and thus its
contents have been zero-initialized implicitly already.

Fix this by explicitly zeroing out the session to enable allocation of
sessions on the stack.

Regression introduced in commit 5452e49f on PR #4967.

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

hash: fix missing error return on production builds

When no hash algorithm has been initialized in a given hash context,
then we will simply `assert` and not return a value at all. This works
just fine in debug builds, but on non-debug builds the assert will be
converted to a no-op and thus we do not have a proper return value.

Fix this by returning an error code in addition to the asserts.

Resolve static check warnings in example code

Using cppcheck on libgit2 sources indicated two warnings in
example code.

merge.c was reported as having a memory leak. Fix applied
was to `free()` memory pointed to by `parents`.

init.c was reported as having a null pointer dereference
on variable arg. Function 'usage' was being called with
a null variable. Changed supplied parameter to empty string.

Multiple hash algorithms

More documentation

Incomplete commondir support

For example, https://git-scm.com/docs/gitrepository-layout says:

    info
    Additional information about the repository is recorded in this directory.
    This directory is ignored if $GIT_COMMON_DIR is set
    and "$GIT_COMMON_DIR/info" will be used instead.

So when looking for `info/attributes`, we need to check the commondir first,
or fallback to "our" `info/attributes`.

As with the preceding commit, the ignore code tries to load code from
info/exclude, and we fail to ignore a non-existent file here.

If creating a repository without a common directory (e.g. by
using `git_repository_new`), then `git_repository_item_path` will
return `GIT_ENOTFOUND` for every file that's usually located in
this directory. While we do not care for this case when looking
up the "info/attributes" file, we fail to properly ignore these
errors when setting up or collecting attributes files. Thus, the
gitattributes lookup is broken and will only ever return
`GIT_ENOTFOUND`.

Fix this issue by properly ignoring `GIT_ENOTFOUND` returned by
`git_repository_item_path`.

The code in the `attr_setup` function is not really matching our
current coding style. Besides alignment issues, it's also hard to
see what functions calls depend on one another because they're
split up over multiple conditional statements.

Fix these issues by grouping together dependent function calls
and adjusting the alignment.

Build with -Werror's equivalent (/WX) on MSVC

Remove warnings

Re-run flaky tests

Our online tests are occasionally flaky since they hit real network
endpoints.  Re-run them up to 5 times if they fail, to allow us to
avoid having to fail the whole build.

Our online tests are occasionally flaky since they hit real network
endpoints.  Re-run them up to 5 times if they fail, to allow us to
avoid having to fail the whole build.

Create an enum that allows us to distinguish between different
hashing algorithms. This enum is embedded into each
`git_hash_ctx` and will instruct the code to which hashing
function the particular request shall be dispatched.

As we do not yet have multiple hashing algorithms, we simply
initialize the hash algorithm to always be SHA1. At a later
point, we will have to extend the `git_hash_init_ctx` function to
get as parameter which algorithm shall be used.

Create a separate `git_hash_sha1_ctx` structure that is specific
to the SHA1 implementation and move all SHA1 functions over to
use that one instead of the generic `git_hash_ctx`. The
`git_hash_ctx` for now simply has a union containing this single
SHA1 implementation, only, without any mechanism to distinguish
between different algortihms.

As a preparatory step to allow multiple hashing APIs to exist at
the same time, split the hashing functions into one layer for generic
hashing and one layer for SHA1-specific hashing. Right now, this is
simply an additional indirection layer that doesn't yet serve any
purpose. In the future, the generic API will be extended to allow for
choosing which hash to use, though, by simply passing an enum to the
hash context initialization function. This is necessary as a first step
to be ready for Git's move to SHA256.

As we will include additional hash algorithms in the future due
to upstream git discussing a move away from SHA1, we should
accomodate for that and prepare for the move. As a first step,
move all SHA1 implementations into a common subdirectory.

Also, create a SHA1-specific header file that lives inside the
hash folder. This header will contain the SHA1-specific header
includes, function declarations and the SHA1 context structure.

Add the `-Wno-documentation-deprecated-sync` switch when compiling with
clang, since our documentation adds `deprecated` markers, but we do not
add the deprecation attribute in the code itself.  (ie, the code is out
of sync with the docs).

In fact, we do not _want_ to mark these items as deprecated in the code,
at least not yet, as we are not quite ready to bother our end-users with
this since they're not going away.