This is going to be used to avoid harmful race conditions in parallel
extraction operations.

For example, a Link to a/b requires that the File at a/b is present.
But, if they are run in parallel, then the File might not be written
before the Link tries to create, and it'll fail with ENOENT.

This gets worse if there's a Directory at a/b/c that unlinks the File so
that it can create a dir.

This addresses a race condition where one archive entry depends on an
earlier archive entry completing its unpack operation.

For example, a File entry followed by a Link to that file would fail if
the File was not written before the link() call was attempted, raising
an ENOENT.

Or, a File entry at a/b could be clobbered mid-write by an entry at
a/b/c.

This was never a problem for npm packages, because those tarballs are
created as a point-in-time snapshot of the package file tree.  Indeed,
even in the generic case, it's a bit of an edge case.  However, this
race condition led to some flaky tests, and could certainly be a problem
in general tar archive usage, especially if someone were to use
tar.update() often to append entries to an archive.

Address unpack race conditions using path reservations

This addresses a race condition where one archive entry depends on an
earlier archive entry completing its unpack operation.

For example, a File entry followed by a Link to that file would fail if
the File was not written before the link() call was attempted, raising
an ENOENT.

Or, a File entry at a/b could be clobbered mid-write by an entry at
a/b/c.

This was never a problem for npm packages, because those tarballs are
created as a point-in-time snapshot of the package file tree.  Indeed,
even in the generic case, it's a bit of an edge case.  However, this
race condition led to some flaky tests, and could certainly be a problem
in general tar archive usage, especially if someone were to use
tar.update() often to append entries to an archive.

This avoids races when entries are zero-length, and emit end()
before the fs object is fully finished and closed.

Fix: #261

When stripping the trailing slash from `files` arguments, we were using
`f.replace(/\/+$/, '')`, which can get exponentially slow when `f`
contains many `/` characters.

Tested a few variants and found one that's faster than the regexp
replacement for short strings, long strings, and long strings containing
many instances of repeated `/` characters.

This is "unlikely but theoretically possible" because it requires that
the user is passing untrusted input into the `tar.extract()` or
`tar.list()` array of entries to parse/extract, which would be quite
unusual.

This moves all the prefix-handling logic into the WriteEntry classes, where it belongs.

Fix: #284

This change uses / as the One True Path Separator, as the gods of POSIX
intended in their divine wisdom.

On windows, \ characters are converted to /, everywhere and in depth.
However, on posix systems, \ is a valid filename character, and is not
treated specially.  So, instead of splitting on `/[/\\]/`, we can now
just split on `'/'` to get a set of path parts.

This does mean that archives with entries containing \ will extract
differently on Windows systems than on correct systems.  However, this
is also the behavior of both bsdtar and gnutar, so it seems appropriate
to follow suit.

Additionally, dirCache pruning is now done case-insensitively.  On
case-sensitive systems, this potentially results in a few extra lstat
calls.  However, on case-insensitive systems, it prevents incorrect
cache hits.

This is a larger refactoring than I tend to prefer to do in a single
commit, but here goes.

- The path normalization of \ to / is made more comprehensive.

- Checking to ensure we aren't overwriting the cwd is done earlier in
  the unpack process, and more thoroughly, so there is less need for
  repetitive checks later.

- The cwd is checked at the start in our recursive mkdir, saving an
  extra fs.mkdir call which would almost always result in an EEXIST.

- Many edge cases resulting in dangling file descriptors were found and
  addressed.  (Much as I complain about Windows stubbornly refusing to
  delete files currently open, it did come in handy here.)

- The Unpack[MAKEFS] methods are refactored for readability, and no
  longer rely on fall-through behavior which made the sync and async
  versions slightly different in some edge cases.

- Many of the tests were refactored to use async rimraf (the better to
  avoid Windows problems) and more modern tap affordances.

Note: coverage on Windows is not 100%, due to skipping many tests that
use symbolic links.  Given the value of having those code paths covered,
I believe that adding istanbul hints to skip coverage of those portions
of the code would be a bad idea.  And given the complexity and hazards
involved in mocking that much of the filesystem implementation, it's
probably best to just let Windows not have 100% coverage.

This is a larger refactoring than I tend to prefer to do in a single
commit, but here goes.

- The path normalization of \ to / is made more comprehensive.

- Checking to ensure we aren't overwriting the cwd is done earlier in
  the unpack process, and more thoroughly, so there is less need for
  repetitive checks later.

- The cwd is checked at the start in our recursive mkdir, saving an
  extra fs.mkdir call which would almost always result in an EEXIST.

- Many edge cases resulting in dangling file descriptors were found and
  addressed.  (Much as I complain about Windows stubbornly refusing to
  delete files currently open, it did come in handy here.)

- The Unpack[MAKEFS] methods are refactored for readability, and no
  longer rely on fall-through behavior which made the sync and async
  versions slightly different in some edge cases.

- Many of the tests were refactored to use async rimraf (the better to
  avoid Windows problems) and more modern tap affordances.

Note: coverage on Windows is not 100%, due to skipping many tests that
use symbolic links.  Given the value of having those code paths covered,
I believe that adding istanbul hints to skip coverage of those portions
of the code would be a bad idea.  And given the complexity and hazards
involved in mocking that much of the filesystem implementation, it's
probably best to just let Windows not have 100% coverage.

Threw a kludge in there to run tap with lower coverage reqs on Windows.