EXT4: reject '..' components that escape the image root during unpack

[jglogan]

Closes#896.

libarchive permits path traversal components (. and ..) in entry pathnames during entry iteration. The library will only extract (in archive_write_disk) an entry if the normalized pathname resolves under the extraction root.

Our EXT4 unarchiver currently prepends '/' to a pathname — an entry's own path, or a hardlink entry's link target, both of which are resolved through the same normalization function — and then attempts to create the corresponding directory entry or link regardless of whether the original relative path would escape the root, yielding a filesystem image that is incorrect at least and corrupt at worst.

Valid OCI archive-type content blobs should never contain escaping pathnames. The unarchiver should treat such pathnames as garbage input and throw an exception on the first such pathname, whether it originates from an entry path or a hardlink target.

Test plan

• swift test --filter ContainerizationEXT4Tests passes (68 tests)
• New regression tests cover: traversal in entry path, traversal in hardlink target, traversal via an already-absolute pathname, harmless self-cancelling .. (accepted and resolved correctly), .. escaping beyond a single real component, and leading .//trailing / tolerance