Symlink resolver and get_software_entry return value change related bugfixes

[nightlark]

Summary

If merged this pull request will fix several issues related to resolving symlinks, and the get_software_entry returning a tuple that needs unpacking when used to get an entry for an "archive" file. Some of the things fixed are described some in #130.

The most complex bug involved symlink resolution, when the extractpath corresponds to a subfolder on the system that the files came from (e.g. C:/Squashfs-usrbin/corresponds to an install prefix of /usr/bin). During symlink resolution, this would result in a symlink such as fileA -> /usr/bin/fileB getting resolved to C:/Squashfs-usrbin/usr/bin/fileB, whereas it should actually be C:/Squashfs-usrbin since C:/Squashfs-usrbin==/usr/bin on the original file system.

One gotcha that still exists is if the symlink points to either a directory outside /usr/bin such as /bin or /sbin (or multiple extract paths correspond to the same install prefix), the symlink resolver doesn't know about any file system trees outside of the current extract path folder being looked at. Addressing this gets complicated though, and ties in with SBOMs created from files that come from completely different systems.

Proposed changes

• Unpack tuple from get_software_entry when processing the "archive" file listed in the config entry
• Look-up files in file_symlinks dictionary using sw_parent variable, rather than the no longer existing entry variable
• Use installPrefix when resolving symlinks to prevent install prefix related directories from getting unnecessarily appended to the extract path
• Output which install paths are symlinks in the metadata to help with debugging and future analysis