Fix: #448

If one of the hard links to a file included in a pack job was not
eventually seen, it would hang forever waiting for the real one, if the
first that is encountered happens to not be the current job.

Fix the problem by only deferring if and only if the job in question is
not the current job, and then if it is encountered again as the current
job, if it's still pending for that reason, proceed with it as the
target 'File' entry.

That module is not future-proof for ESM, or TS compatible.

re: #458 (comment)

Thanks @jakebailey

A PAX extended header (x/g) describes the *next file entry*, per POSIX
pax, not the GNU long-name (L) / long-link (K) or further PAX (x/g)
headers that may sit between it and that file. Header.decode previously
applied the pending ex/gex overrides (notably size) to whatever header
was decoded next, including those intermediary extension headers. A
crafted stream ordered x(size=N) -> L -> file would advance the cursor
by N for the L header instead of by L's true payload length,
desynchronizing the parser relative to GNU tar, libarchive, Python
tarfile and the (now-fixed) Rust tar crates. This is a tar
interpretation-conflict / file-smuggling primitive (CWE-436).

Only apply extended headers to entries that represent known filesystem
entry types.

EDIT(@isaacs):

- Added test
- Updated block-list of meta types to allow-list of fs types.

Fix: GHSA-vmf3-w455-68vh