test: clean up memory leaks

Introduce `git_path_validate_filesystem` which validates (absolute) on-disk
paths and `git_path_validate_workdir` to perform validations on (absolute)
working directory paths.  These functions are useful as there may be system
limitations on on-disk paths, particularly on Windows (for example,
enforcing MAX_PATH).

For working directory paths, these limitations may be per-repository, based
on the `core.longpaths` configuration setting.

If we want to validate more and different types of paths, the name
`git_path_validate` makes that easier and more expressive.  We can add,
for example, `git_path_validate_foo` while the current name makes that
less ergonomic.

Add a function that takes a (possibly) relative UTF-8 path and emits a
UTF-16 path with forward slashes translated to backslashes.  If the
given path is, in fact, absolute, it will be translated to absolute path
handling rules.

The path canonicalization functions on win32 are intended to
canonicalize absolute paths; those with prefixes.  In other words,
things start with drive letters (`C:\`), share names (`\\server\share`),
or other prefixes (`\\?\`).

This function removes leading `..` that occur after the prefix but
before the directory/file portion (eg, turning `C:\..\..\..\foo` into
`C:\foo`).  This translation is not appropriate for local paths.

Windows/DOS only supports drive letters that are alpha characters A-Z.
However, you can `subst` any one-character as a drive letter, including
numbers or even emoji.  Test that we can identify emoji as drive
letters.

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>

Windows-based systems treat paths starting with '\' as absolute,
either referring to the current drive's root (e.g. "\foo" might
refer to "C:\foo") or to a network path (e.g. "\\host\foo"). On
the other hand, (most?) systems that are not based on Win32
accept backslashes as valid characters that may be part of the
filename, and thus we cannot treat them to identify absolute
paths.

Change the logic to only paths starting with '\' as absolute on
the Win32 platform. Add tests to avoid regressions and document
behaviour.