attr: rename constants and macros for consistency

Our enumeration values are not generally suffixed with `T`.  Further,
our enumeration names are generally more descriptive.

Change API instances of `fromnoun` to `from_noun` (with an underscore)

object: rename git_object__size to git_object_size

The majority of functions are named `from_something` (with an
underscore) instead of `fromsomething`.  Update the tag function for
consistency with the rest of the library.

The majority of functions are named `from_something` (with an
underscore) instead of `fromsomething`.  Update the index functions for
consistency with the rest of the library.

We don't use double-underscores in the public API.

The majority of functions are named `from_something` (with an
underscore) instead of `fromsomething`.  Update the blob functions for
consistency with the rest of the library.

The only function that is named `issomething` (without underscore) was
`git_oid_iszero`.  Rename it to `git_oid_is_zero` for consistency with
the rest of the library.

Replace fnmatch with wildmatch

Documentation fixes

Docurium seems to choke on this header because it can't see both
git_indexer_progress & git_indexer_progress_cb, let's add the include.

The `fnmatch` code has now been completely replaced by
`wildmatch`, same as upstream git.git has been doing in 2014.
Remove it.

Upstream git has converted to use `wildmatch` instead of
`fnmatch`. Convert our gitattributes logic to use `wildmatch` as
the last user of `fnmatch`. Please, don't expect I know what I'm
doing here: the fnmatch parser is one of the most fun things to
play around with as it has a sh*tload of weird cases. In all
honesty, I'm simply relying on our tests that are by now rather
comprehensive in that area.

The conversion actually fixes compatibility with how git.git
parser "**" patterns when the given path does not contain any
directory separators. Previously, a pattern "**.foo" erroneously
wouldn't match a file "x.foo", while git.git would match.

Remove the new-unused LEADINGDIR/NOLEADINGDIR flags for
`git_attr_fnmatch`.

We currently use `p_fnmatch` to compute whether a given "gitdir:"
or "gitdir/i:" conditional matches the current configuration file
path. As git.git has moved to use `wildmatch` instead of
`p_fnmatch` throughout its complete codebase, we evaluate
conditionals inconsistently with git.git in some special cases.

Convert `p_fnmatch` to use `wildmatch`. The `FNM_LEADINGDIR` flag
cannot be translated to `wildmatch`, but in fact git.git doesn't
use it here either. And in fact, dropping it while we go
increases compatibility with git.git.

When evaluating "gitdir:" and "gitdir/i:" conditionals, we
currently compare the given pattern with the value of
`git_repository_path`. Thing is though that `git_repository_path`
returns the gitdir path with trailing '/', while we actually need
to match against the gitdir without it.

Fix this issue by stripping the trailing '/' previous to
matching. Add various tests to ensure we get this right.

The function `do_match_gitdir` has some horribly named parameters
and variables. Rename them to improve readability. Furthermore,
fix a potentially undetected out-of-memory condition when
appending "**" to the pattern.

Upstream git.git has converted its codebase to use wildcard in
favor of fnmatch in commit 70a8fc999d (stop using fnmatch (either
native or compat), 2014-02-15). To keep our own regex-matching in
line with what git does, convert all trivial instances of
`fnmatch` usage to use `wildcard`, instead. Trivial usage is
defined to be use of `fnmatch` with either no flags or flags that
have a 1:1 equivalent in wildmatch (PATHNAME, IGNORECASE).

We're about to phase out our bundled fnmatch implementation as
git.git has moved to wildmatch long ago in 2014. To make it
easier to spot which files are stilll using fnmatch, remove the
implicit "fnmatch.h" include in "posix.h" and instead include it
explicitly.

In commit 70a8fc999d (stop using fnmatch (either native or
compat), 2014-02-15), upstream git has switched over all code
from their internal fnmatch copy to its new wildmatch code. We
haven't followed suit, and thus have developed some
incompatibilities in how we match regular expressions.

Import git's wildmatch from v2.22.0 and add a test suite based on
their t3070-wildmatch.sh tests.

Removal of `p_fallocate`

By now, we have repeatedly failed to provide a nice
cross-platform implementation of `p_fallocate`. Recent tries to
do that escalated quite fast to a set of different CMake checks,
implementations, fallbacks, etc., which started to look real
awkward to maintain. In fact, `p_fallocate` had only been
introduced in commit 4e3949b7 (tests: test that largefiles can
be read through the tree API, 2019-01-30) to support a test with
large files, but given the maintenance costs it just seems not to
be worht it.

As we have removed the sole user of `p_fallocate` in the previous
commit, let's drop it altogether.

The `p_fallocate` platform is currently in use in our tests,
only, but it proved to be quite burdensome to get it implemented
in a cross-platform way. The only "real" user is the test
object::tree::read::largefile, where it's used to allocate a
large file in the filesystem only to commit it to the repo and
read its object back again. We can simplify this quite a bit by
just using an in-memory buffer of 4GB. Sure, this cannot be used
on platforms with low resources. But creating 4GB files is not
any better, and we already skip the test if the environment
variable "GITTEST_INVASIVE_FS_SIZE" is not set. So we're arguably
not worse off than before.

Modularize our TLS & hash detection

The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been
streamlined. Previously we would have accepted not quite working
configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as
the OpenSSL detection only ran with `USE_HTTPS`, the link would fail.

The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`,
which takes the values "CollisionDetection/Backend/Generic", to better
match how the "hashing backend" is selected, the default (ON) being
"CollisionDetection".

Note that, as `SHA1_BACKEND` is still used internally, you might need to
check what customization you're using it for.

tests: merge::analysis: use test variants to avoid duplicated test suites

Rename options initialization functions

deps: ntlmclient: disable implicit fallthrough warnings

In libgit2 nomenclature, when we need to verb a direct object, we name
a function `git_directobject_verb`.  Thus, if we need to init an options
structure named `git_foo_options`, then the name of the function that
does that should be `git_foo_options_init`.

The previous names of `git_foo_init_options` is close - it _sounds_ as
if it's initializing the options of a `foo`, but in fact
`git_foo_options` is its own noun that should be respected.

Deprecate the old names; they'll now call directly to the new ones.

The ntlmclient dependency has quite a lot of places with implicit
fallthroughs. As at least modern GCC has enabled warnings on
implicit fallthroughs by default, the developer is greeted with a
wall of warnings when compiling that dependency.

Disable implicit fallthrough warnings for ntlmclient to fix this
issue.

gitignore with escapes

Handle URLs with a colon after host but no port

Our bundled http-parser includes bugfixes, therefore we should prefer
our http-parser until such time as we can identify that the system
http-parser has these bugfixes (using a version check).

Since these bugs are - at present - minor, retain the ability for users
to force that they want to use the system http-parser anyway.  This does
change the cmake specification so that people _must_ opt-in to the new
behavior knowingly.

Since commit 394951ad (tests: allow for simple data-driven
tests, 2019-06-07), we have the ability to run a given test suite
with multiple variants. Use this new feature to deduplicate the
test suites for merge::{trees,workdir}::analysis into a single
test suite.

Merge analysis support for bare repos

Add memleak check docs

In our attributes pattern parsing code, we have a comment that
states we might have to convert '\' characters to '/' to have
proper POSIX paths. But in fact, '\' characters are valid inside
the string and act as escape mechanism for various characters,
which is why we never want to convert those to POSIX directory
separators. Furthermore, gitignore patterns are specified to only
treat '/' as directory separators.

Remove the comment to avoid future confusion.

When determining the trailing space length, we need to honor
whether spaces are escaped or not. Currently, we do not check
whether the escape itself is escaped, though, which might
generate an off-by-one in that case as we will simply treat the
space as escaped.

Fix this by checking whether the backslashes preceding the space
are themselves escaped.