[Feature request] Add support for pseudo files

Thanks for this awesome project, I began using your utility since around 0.12.

Pseudo file support has many potential benefits, but the one feature I am most interested in, is the use of specifying UID/GID, along with original timestamp the file has. Presently, squashfs-tools has this feature since around [version 4.6](https://github.com/plougher/squashfs-tools/releases/tag/4.6), released on 2023-03-18. Many old Unix-like archive formats (tar, cpio) contains metadata, such as user/group names, their IDs, in addition to timestamps of when the file was added. These would be sadly lost if the contents of the archive are decompressed, and recompressed into DwarFS for data preservation. It would also be infeasible to make use of `fakeroot` for instance to try and replicate original UID/GID as these lacked any standardisation; wheel group ID could either be 0 or 1 for instance in some older Unix-like environments, but under modern Linux, it is generally 998.

Cases of where pseudo files has its use, starting with the problem at hand:
* 4.4BSD for instance, creates a FTP directory named "hidden" with very specific set of permission, 444 or read-only access for all as root owned.
* Certain old Unix-like tarballs omits last-modified timestamp along with UID/GID. If these were extracted under modern Linux, it would default to effective UID/GID of the one extracting it, with the timestamp of when the extraction took place.
* Hard links also does not translate well.

To:
* Specify the original directory perms and as root owned.
* Provide it with a timestamp of a file that was last updated, with the UID/GID that closely matches to the original.
* Make use of symlinks in lieu.

All these as comments in the pseudo file, noting any necessary changes.

The aim here isn't to rewrite the history of the various extracted archives, in a specific manner that contradicts to however it was represented in the various sources, but to systematically document these inside a definition file of some form, and to potentially allow the recreation of the image with as many of these metadata intact. In a way, this may look like it is related to [extended attributes](https://github.com/mhx/dwarfs/issues/160), but in my examples it is not, and could thus be also used as a makeshift solution towards it.

What are your thoughts on this?

The issue identifies no implementation files, tests, or entry points. Start by defining the pseudo-file format and the supported UID/GID, timestamp, permissions, ownership, and symlink semantics described here. Done means the design is agreed and the image can preserve and recreate the specified metadata.

Written by the indexing model from the issue text.