Allow users to specify additional repository extensions that they want
to support.  For example, callers can specify that they support
`preciousObjects` and then may open repositories that support
`extensions.preciousObjects`.

Similarly, callers may opt out of supporting extensions that the library
itself supports.

Like on Windows ':' is used for volume names in absolute paths.

Introduce GIT_OPT_SET_ODB_LOOSE_PRIORITY and GIT_OPT_SET_ODB_PACKED_PRIORITY
to allow overriding the default priority values for the default ODB
backends. Libgit2 has historically assumed that most objects for long-
running operations will be packed, therefore GIT_LOOSE_PRIORITY is
set to 1 by default, and GIT_PACKED_PRIORITY to 2.
When a client allows libgit2 to set the default backends, they can
specify an override for the two priority values in order to change
the order in which each ODB backend is accessed.

* 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.