* Change the default of the file limit to 0 (unlimited).
* Changed the heuristic to close files to be the file that contains the
  least-recently-used window such that the window is the
  most-recently-used in the file, and the file does not have in-use
  windows.
* Parameterized the filelimit test to check for a limit of 1 and 100
  open windows.

There are some cases in which repositories accrue a large number of
packfiles. The existing mwindow limit applies only to the total size of
mmap'd files, not on their number. This leads to a situation in which
having lots of small packfiles could exhaust the allowed number of open
files, particularly on macOS, where the default ulimit is very low
(256).

This change adds a new configuration parameter
(GIT_OPT_SET_MWINDOW_FILE_LIMIT) that sets the maximum number of open
packfiles, with a default of 128. This is low enough so that even macOS
users should not hit it during normal use.

Based on PR #5386, originally written by @josharian.

Fixes: #2758

Stop returning a void for functions, future-proofing them to allow them
to fail.

Allow users to opt-in to expect/continue handling when sending a POST
and we're authenticated with a "connection-based" authentication
mechanism like NTLM or Negotiate.

If the response is a 100, return to the caller (to allow them to post
their body).  If the response is *not* a 100, buffer the response for
the caller.

HTTP expect/continue is generally safe, but some legacy servers
have not implemented it correctly.  Require it to be opt-in.

Remove an `inttypes.h` header that is too large in scope, and far too
public.

For Visual Studio 2012 and earlier (ie, `_MSC_VER < 1800`), we do need
to include `stdint.h` in our public headers, for types like `uint32_t`.

Internally, we also need to define `PRId64` as a printf formatting
string when it is not available.

Recent GCC enables `-Wunused-const-variables`, which makes output quite
noisy.  Disable unused warnings for our deprecated variables.

Since we now always build the library with cdecl calling conventions,
our callbacks should be decorated as such so that users will not be able
to provide callbacks defined with other calling conventions.

The `GIT_CALLBACK` macro will inject the `__cdecl` attribute as
appropriate.

The recommendation from engineers within Microsoft is that libraries
should have a calling convention specified in the public API, and that
calling convention should be cdecl unless there are strong reasons to
use a different calling convention.

We previously offered end-users the choice between cdecl and stdcall
calling conventions.  We did this for presumed wider compatibility: most
Windows applications will use cdecl, but C# and PInvoke default to
stdcall for WINAPI compatibility.  (On Windows, the standard library
functions are are stdcall so PInvoke also defaults to stdcall.)

However, C# and PInvoke can easily call cdecl APIs by specifying an
annotation.

Thus, we will explicitly declare ourselves cdecl and remove the option
to build as stdcall.