test: add trailing-slash corner-case

[rmg]

The logic for checking if an entry is marked as a file but has a
trailing '/' in the path trips over files that happen to be under a
99-character path that is the perfect length for the 100-byte truncated
path to look like it is has a trailing / when it really doesn't.

<1: header, link, "././@LongLink">
<2: "full-path-to-file-inside-dir/filename">
<3: header, file, "first-99-bytes-of-full-path/">
<4: body of file>

The parser appears to treat the above as:

1. parse link entry as normal
2. parse metadata frame
3. parse file entry as directory entry
4. assume next frame is next entry

This happens with tarballs generated by GNU Tar, but it is not
related to the gnu tar format.

The way BSD tar generates the above is:

<frame: header, file, "path-after-the-slash", prefix>
<frame: body of file>

It appears that the root cause is GNU Tar doesn't use the prefix field
of the POSIX tar header and instead relies on the link frame and assumes
that the path in the following "real" file entry is mostly advisory so
it doesn't matter that it is truncated at 100 bytes.

BSD Tar, on the other hand, makes use of the prefix field and instead
only puts the file portion of the path in the path field.

The take away here is that if you are not using npm to tar up your
bundles, at least use BSD Tar instead of GNU Tar, because even after
fixing this there will be a long tail of broken versions of npm to
support.

[rmg]

@isaacs this is the reduced test case I was describing to you

[rmg]

Here's some hex-dumps of the troublesome tarball:

https://gist.github.com/rmg/922ce5256e535a77682d19037e8fa622

[isaacs]

Thank you! I'll take a look soon.