Fix building against system http-parser library by fixing
the find_package() argument.  It seems to have been accidentally changed
from HTTPParser to HTTP_Parser in de178d36, effectively making
the build against system library fail to find it:

```
CMake Warning at cmake/SelectHTTPParser.cmake:3 (find_package):
  By not providing "FindHTTP_Parser.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "HTTP_Parser", but CMake did not find one.

  Could not find a package configuration file provided by "HTTP_Parser" with
  any of the following names:

    HTTP_ParserConfig.cmake
    http_parser-config.cmake

  Add the installation prefix of "HTTP_Parser" to CMAKE_PREFIX_PATH or set
  "HTTP_Parser_DIR" to a directory containing one of the above files.  If
  "HTTP_Parser" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  src/CMakeLists.txt:97 (include)

CMake Error at cmake/SelectHTTPParser.cmake:11 (message):
  http-parser support was requested but not found
Call Stack (most recent call first):
  src/CMakeLists.txt:97 (include)
```

libgit2 v1.4

Fix crashes in example programs on Windows (sprintf_s not compatible with snprintf)

merge: fix overlap between GIT_MERGE_FILE_FAVOR__CONFLICTED and GIT_MERGE_FILE_SIMPLIFY_ALNUM

meta: add a release configuration file

diff_file: fix crash if size of diffed file changes in workdir

Let's let GitHub handle our release notes as much as possible:
https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes

mktmp: improve our temp file creation

We made the flags that enable recursive merge internal, on the
assumption that nobody would want them and they're hard to reason about.
(Giving people an option that nobody wants is just extra noise.)

However, it made it hard for _us_ to reason about.  There's no good
reason to keep it private, let's just make it public and push that
cognitive load onto our poor users.  But they should expect it, they're
dealing with git, after all.

When we know that we know a file's size, and the file's size changes,
fail.

When we know the file size (because we're producing it from a working
directory iterator, or an index with an up-to-date cache) then set a
flag indicating as such.  This removes the ambiguity about a 0 file
size, which could indicate that a file exists and is 0 bytes, or that we
haven't read it yet.

Move the empty tree ID into a global space so that it can be generally
used.

This test was also provided by @jorio
https://github.com/libgit2/libgit2/pull/6208#issuecomment-1034072050

Skip new_file_size non-zero test, custom error message if file changed in workdir

Co-authored-by: Edward Thomson <ethomson@github.com>

"diff_file_content_load_workdir_file()" maps a file from the workdir
into memory. It uses git_diff_file.size to determine the size of the
memory mapping.

If this value goes stale, the mmaped area would be sized incorrectly.
This could occur if an external program changes the contents of the
file after libgit2 had cached its size. This used to segfault if the
file becomes smaller (mmaped area too large).

This patch causes diff_file_content_load_workdir_file to fail without
crashing if it detects that the file size has changed.

Fetch by object id

We have our own temporary file creation function now in
`git_futils_mktmp`, remove the others since they may be terrible on some
platforms.

`mktemp` on mingw is exceedingly deficient, using a single monotonically
increasing alphabetic character and the pid.  We need to use our own
random number generator for temporary filenames.

Introduce `git_rand`, a PRNG based on xoroshiro256**, a fast,
all-purpose pseudo-random number generator: https://prng.di.unimi.it

The PRNG will be seeded by the system's entropy store when possible,
falling back to current time and system data (pid, uptime, etc).
Inspiration for this was taken from libressl, but since our PRNG is
not used for cryptographic purposes (and indeed currently only generates
a unique temp file name that is written in a protected directory),
this should be more than sufficient.

Our implementation of xoroshiro256** was taken almost strictly from
the original author's sources, but was tested against PractRand to
ensure that there were no foolish mistranslations:

```
RNG_test using PractRand version 0.94
RNG = RNG_stdin64, seed = unknown
test set = core, folding = standard (64 bit)

rng=RNG_stdin64, seed=unknown
length= 256 megabytes (2^28 bytes), time= 2.9 seconds
  no anomalies in 210 test result(s)

rng=RNG_stdin64, seed=unknown
length= 512 megabytes (2^29 bytes), time= 6.2 seconds
  no anomalies in 226 test result(s)

rng=RNG_stdin64, seed=unknown
length= 1 gigabyte (2^30 bytes), time= 12.7 seconds
  no anomalies in 243 test result(s)

rng=RNG_stdin64, seed=unknown
length= 2 gigabytes (2^31 bytes), time= 25.4 seconds
  no anomalies in 261 test result(s)

rng=RNG_stdin64, seed=unknown
length= 4 gigabytes (2^32 bytes), time= 50.6 seconds
  no anomalies in 277 test result(s)

rng=RNG_stdin64, seed=unknown
length= 8 gigabytes (2^33 bytes), time= 104 seconds
  no anomalies in 294 test result(s)
```

push: Prepare pack before sending pack header.

odb: check for write failures

Co-authored-by: Edward Thomson <ethomson@github.com>

For large pushes, preparing the pack can take a while. Currently we
send the pack header first, followed by preparing the pack and then
finally sending the pack. Unfortunately github.com will terminate
a git-receive-pack command over http if it is idle for more than 10
seconds. This is easily exceeded for a large push, and so the push is
rejected with a Broken Pipe error.

This patch moves the pack preparation ahead of sending the pack header,
so that the timeout is avoided.

prepare_pack() can be called multiple times but will only do the work
once, so the original PREPARE_PACK call inside git_packbuilder_foreach()
remains.

Allocate flags in git_merge_flag_t and git_merge_file_flag_t
for internal usage to prevent accidental double allocation.

GIT_MERGE_FILE__CONFLICTED

This is to avoid a possible problem where the value is set to the
same as GIT_MERGE_FILE_SIMPLIFY_ALNUM in git_merge_file_flag_t

SHA256: early preparation

Provide a mechanism for (internal) users to determine a remote's
capabilities from the transport.