The path reservation system prevents multiple file entries clobbering
one another while in flight, while allowing maximal parallelization
in unpacking otherwise.

However, on case-insensitive file systems, this can still introduce a
race condition if the entries in the archive have different cases, as
capital and lowercase entries will not be treated as reserving the same
path.

Normalize slashes and cases immediately when reserving paths, such that
paths which differ only in case or slash repetition are treated as
identical paths.

Fix tar.Unpack() to skip extraction of hardlinks and symlinks when a
'strip' option is provided, if the entry linkpath would be completely
stripped.

Previously, the linkpath would not be stripped if it had fewer path parts
than the strip option.

This matches the behavior of modern versions of bsdtar.  Gnutar has the
same extraction semantics, but emits a warning when the resulting
linkpath is completely stripped.

This prunes the dirCache in a way that catches unicode filename matches.

If a symbolic link is encountered on Windows, the entire dirCache is
cleared, as 8.3 shortname collisions may result in a path escape
vulnerability in the case of symbolic links.  If such a collision occurs
in the case of other types of entries, it is not such a big problem,
because the unpack will fail.

This updates the path reservation system such that it will properly
await any paths that match based on unicode normalization.

On windows, because 8.3 shortnames can collide in ways that are
undetectable by any reasonable means, all unpack parallelization is
simply disabled.

On Windows, a path like `c:foo` is not considered "absolute", but if the
cwd it's being resolved against is on a different drive letter, then
`resolve(cwd, path)` will not end up contained within `cwd`, even in the
absence of `..` portions.

This change strips path roots from all paths prior to being resolved
against the extraction target folder, even if such paths are not
"absolute".

Additionally, a path starting with a drive letter and then two dots,
like `c:../`, would bypass the check for `..` path portions.  This is
now being checked properly.

Finally, a defense in depth check is added, such that if the
entry.absolute is outside of the extraction taret, and we are not in
preservePaths:true mode, a warning is raised on that entry, and it is
skipped.  Currently, it is believed that this check is redundant, but it
did catch some oversights in development.