Fix: GHSA-r6q2-hw4h-h46w

PR-URL: #450
Credit: @nwalters512
Close: #450
Reviewed-by: @isaacs

EDIT(@isaacs): fixed for test coverage and to disallow absolute
linkpaths that contain `..`

This avoids a situation in the async Pack class where a detected Link
and File pair can end up with the Link ahead of the File in the archive,
meaning that it'll throw an error when it tries to unpack, because the
hardlink target will not exist yet.

Fix: #448

Fix: GHSA-34x7-hfp2-rc4v

The issue here is that *hard* links are resolved relative to the unpack
cwd, so if they have `..`, they cannot possibly be valid, same as files
and for the same reason. The loosening of this restriction for symbolic
links should have been limited by type, allowing this error.

Prevent any `Link` or `SymbolicLink` entry from being created if its
`linkpath` would target a location that is through a symbolic link from
the current working directory.

This matches the behavior of `bsdtar` for hard links, and is somewhat
more restrictive in applying the same logic to symbolic links as well.

Unpacking links with targets that extend through symlink folders is
allowed if `preservePaths` option is enabled, as this disables all
protective link checking by design, and is only designed for use with
trusted input.

Fix: GHSA-83g3-92jg-28cx

UnpackSync[ENSURE_NO_SYMLINK] previously constructed SymlinkError's
"into" path using the full original linkpath parts array, which could
produce misleading diagnostics.

Build the "into" path from the original `cwd` value and the `parts`
list.