win32: use NT-prefixed "\\?\" paths

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:\)
tree: Check for `.git` with case insensitivy
index: Check for valid paths before creating an index entry
checkout: disallow bad paths 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.
reference_create: validate loose names

Validate loose reference names on Win32.
checkout: disallow bad paths on HFS

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.
path: Use UTF8 iteration for HFS chars
Introduce core.protectHFS and core.protectNTFS

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