Bump version to 0.21.4

A rule "src" in src/.gitignore must only match subdirectories of
src/. The current code does not include this context in the match rule
and would thus consider this rule to match the top-level src/ directory
instead of the intended src/src/.

Keep track fo the context in which the rule was defined so we can
perform a prefix match.

A rule can only negate something which was explicitly mentioned in the
rules before it. Change our parsing to ignore a negative rule which does
not negate something mentioned in the rules above it.

While here, fix a wrong allocator usage. The memory for the match string
comes from pool allocator. We must not free it with the general
allocator. We can instead simply forget the string and it will be
cleaned up.

Given

    top
    !top/foo

in an ignore file, we should not unignore top/foo. This is an
implementation detail of the git code leaking, but that's the behaviour
we should show.

A negation rule can only negate an exact rule it has seen before.

[maint/v0.21] Fix build of tests with mingw

very, very partial backport of 2f795d8f to maint/v0.21 branch

without this include, O_RDWR and O_CREAT are undeclared when building tests/path/win32.c with mingw

We need to know what wchar_t and MAX_PATH are. Including common.h takes
care of that for us.

GIT_BEGIN/END_DECL were missing from sys/refs.h and preventing
compilation with g++ as the symbol were mangled.

We need these directories to exist so cl_git_mkfile() can create the
files we ask it to.

Validate HFS ignored char ".git" paths when `core.protectHFS` is
specified.  Validate NTFS invalid ".git" paths when `core.protectNTFS`
is specified.

HFS filesystems ignore some characters like U+200C.  When these
characters are included in a path, they will be ignored for the
purposes of comparison with other paths.  Thus, if you have a ".git"
folder, a folder of ".git<U+200C>" will also match.  Protect our
".git" folder by ensuring that ".git<U+200C>" and friends do not match it.

Validate loose reference names on Win32.

Disallow:
 1. paths with trailing dot
 2. paths with trailing space
 3. paths with trailing colon
 4. paths that are 8.3 short names of .git folders ("GIT~1")
 5. paths that are reserved path names (COM1, LPT1, etc).
 6. paths with reserved DOS characters (colons, asterisks, etc)

These paths would (without \\?\ syntax) be elided to other paths - for
example, ".git." would be written as ".git".  As a result, writing these
paths literally (using \\?\ syntax) makes them hard to operate with from
the shell, Windows Explorer or other tools.  Disallow these.

When turning UTF-8 paths into UCS-2 paths for Windows, always use
the \\?\-prefixed paths.  Because this bypasses the system's
path canonicalization, handle the canonicalization functions ourselves.

We must:
 1. always use a backslash as a directory separator
 2. only use a single backslash between directories
 3. not rely on the system to translate "." and ".." in paths
 4. remove trailing backslashes, except at the drive root (C:\)

Backport two important changes to 0.21 branch

We're freeing the memory which holds the locks so we must make sure that
the locking function doesn't try to use it.

A non-readable mapping of a file causes an access violation in
the pack tests. Always use PROT_READ to work around this.

More backports to 0.21

FindFirstFile will fail with INVALID_HANDLE_VALUE if there are no
children to the given path, which can happen if the given path is a
file (and obviously has no children) or if the given path is an empty
mount point.  (Most directories have at least directory entries '.'
and '..', but ridiculously another volume mounted in another drive
letter's path space do not, and thus have nothing to enumerate.)

If FindFirstFile fails, check if this is a directory-like thing
(a mount point).

A reparse point that is an IO_REPARSE_TAG_MOUNT_POINT could be
a junction or an actual filesystem mount point.  (Who knew?)
If it's the latter, its reparse point will report the actual
volume information \??\Volume{GUID}\ and we should not attempt
to dereference that further, instead readlink should report
EINVAL since it's not a symlink / junction and its original
path was canonical.

Yes, really.