We just safe-guarded `.git` against NTFS Alternate Data Stream-related
attack vectors, and now it is time to do the same for `.gitmodules`.

Note: In the added regression test, we refrain from verifying all kinds
of variations between short names and NTFS Alternate Data Streams: as
the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it
is enough to test one in order to know that all of them are guarded
against.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Right now, there's quite a lot of different function calls to determine
whether a path component matches a specific name after normalization
from the filesystem. We have a function for each of {gitattributes,
gitmodules, gitignore} multiplicated with {generic, NTFS, HFS} checks.
In the long time, this is unmaintainable in case there are e.g. new
filesystems with specific semantics, blowing up the number of functions
we need to implement.

Replace all functions with a simple `git_path_is_gitfile` function,
which accepts an enum pointing out the filename that is to be checked
against as well as the filesystem normalizations to check for. This
greatly simplifies implementation at the expense of the caller having to
invoke a somewhat longer function call.

Any part of the library which asks the question can pass in the mode to have it
checked against `.gitmodules` being a symlink.

This is particularly relevant for adding entries to the index from the worktree
and for checking out files.

We may take in names from the middle of a string so we want the caller to let us
know how long the path component is that we should be checking.

These can't go into the public API yet as we don't want to introduce API or ABI
changes in a security release.

Given a path component it knows what to pass to the filesystem-specific
functions so we're protected even from trees which try to use the 8.3 naming
rules to get around us matching on the filename exactly.

The logic and test strings come from the equivalent git change.