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.

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.

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.

GetProcAddress is prototyped to return a `FARPROC`, which is meant to be
a generic function pointer.  It's literally `int (FAR WINAPI * FARPROC)()`
which gcc complains if you attempt to cast to a `void (*)(GIT_SRWLOCK *)`.
Cast to a `void *` before casting to avoid warnings about the arguments.

GetProcAddress is prototyped to return a `FARPROC`, which is meant to be
a generic function pointer.  It's literally `int (FAR WINAPI * FARPROC)()`
which gcc complains if you attempt to cast to a `void (*)(GIT_SRWLOCK *)`.
Cast to a `void *` before casting to avoid warnings about the arguments.

MinGW does not define DWORD_MAX.  Specify it when it's not defined.

MinGW uses gcc, which expects POSIX formatting for printf, but uses the
Windows C library, which uses its own format specifiers.  Therefore, it
gets confused about format specifiers.  Disable warnings for format
specifiers.

RtlCaptureStackBackTrace is well-defined in Windows, no need to redefine
it.

For MSVC, support warnings as errors by providing the /WX compiler
flags.  (/WX is the moral equivalent of -Werror.)

Disable warnings as errors ass part of xdiff, since it contains
warnings.  But as a component of git itself, we want to avoid skew and
keep our implementation as similar as possible to theirs.  We'll work
with upstream to fix these issues, but in the meantime, simply let those
continue to warn.

Move `git_win32__file_attribute_to_stat` to a regular function instead
of an inlined function.  This helps avoid header ordering issues and
declarations.

Ensure that the server has not sent us overly-large sideband messages
(ensure that they are no more than `INT_MAX` bytes), then cast to `int`.

Our progress information messages are short (and bounded by their format
string), cast the length to int for callers.

We keep the treebuilder entrycount as a `size_t` - return that instead
of downcasting to an `unsigned int`.  Callers who were storing this
value in an `unsigned int` will continue to downcast themselves, so
there should be no behavior change for callers.

The `git__utf8_charlen` now takes `size_t` as the buffer length, since
it contains the full length of the buffer at the current position.  It
now returns `-1` in all cases where utf8 codepoints are invalid, since
callers only care about a valid length of a sequence of codepoints, or
if the current position is not valid utf8.

Only read at most INT_MAX from the underlying stream, so that we can
accurately return the number of bytes read.

Since callers are not guaranteed to get as many bytes as requested (due
to availability of input), this is safe and callers should call in a
loop until EOF.

Explicitly truncate the file size to a `uint32_t`.