COMMON: Clean up archive path handling, add getFileName and getPathInArchive to ArchiveMember

[elasota]

Reworked this to hopefully minimize regression risk. This partially refactors archive path handling to better handle full paths and alternate path separators.

The main thing motivating this is a few things:

• The default implementation of Archive::listMatchingMembers calls getName to determine the path to match, which acts as if getName returns a full path, except it may not. In particular, FSNode archive members always return only the file name.
• ArchiveMember lacks a way to get the path of a file relative to the archive root.

I mainly want these to make a VFS for mTropolis to make dealing with installers easier (basically, the VFS would be an archive containing hardlinks to other archives - in order do to that though, it needs to be possible to scan an archive subpath).

The previous version of this tried just making getName always return only the filename, but that would require checking a LOT of engines for regressions which I think makes this too big of a project. Instead, this adds getFileName and getPathInArchive and deprecates getName. This is absolutely NOT guaranteed to work correctly with all existing cases (some engines may be returning full paths from getFileName, if they actually support them), but it will provide a smoother path to making this work in a sensible way.

This also changes GenericArchiveMember to accept a path instead of a string. This should transparently support existing cases since getName will return the path converted using the same path separator, except for StuffIt (see below).

This also changes FSDirectory to return FSDirectoryFile as the archive member type. The reason for this is so that when calling getMember with a subpath of a directory, it will return a FSDirectoryFile for which getPathInArchive returns the relative path from the directory that getMember was called on instead of the parent of the file, keeping the principle that passing getPathInArchive back to getMember should always return the same thing.

The only case this will cause a change in behavior is directly constructing a path using an incompatible separator, which is currently only possible for StuffIt and VISE archives since they are the only ones that use alternate path separators, and the StuffIt loader flattens the directory tree by default.

However, this should improve support for MacOS filenames with slashes in them, since StuffItArchive::getMember will no longer interpret the slash as a separator.

[mistydemeo]

clang has a new warning with this branch:

./common/fs.h:252:30: warning: 'createReadStream' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
        virtual SeekableReadStream *createReadStream() const;
                                    ^
./common/archive.h:60:30: note: overridden virtual function is here
        virtual SeekableReadStream *createReadStream() const = 0; /*!< Create a read stream. */
                                    ^
1 warning generated.

[elasota]

Fixed, though that looks like a pre-existing problem.

[sev-]

Thank you!