fix(linux): add logic to parse the upstream package name

[JamieMagee]

The package name does not always line up 100% with the upstream or source name. For example some Linux distributions suffix the major version to differentiate i.e. python2 and python3. These should both be mapped back to python.

This PR also adds ResourceUtilities with the LoadTextAsync method, and also bundles a Resources directory in test projects. This should make it easier to load mocks from files for tests. Instead of having to embed them in the C# source.

[github-actions]

👋 Hi! It looks like you modified some files in the Detectors folder.
You may need to bump the detector versions if any of the following scenarios apply:

• The detector detects more or fewer components than before
• The detector generates different parent/child graph relationships than before
• The detector generates different devDependencies values than before

If none of the above scenarios apply, feel free to ignore this comment 🙂

[tofay]

I don't think we can consistently choose either the binary package name or the source package name for all RPM based distros. Mariner publishes vulnerabilities under source package names, as does SUSE. But RHEL (also used for centos vulns) publish vulnerabilities under the binary package names.

[JamieMagee]

Okay, but we just need a more granular decision tree here?

[tofay]

Yes. (Though per my email, I'm not sure if component governance might have a need for both binary and source package name.)

[tofay]

Given that component-detection doesn't do vulnerability scanning itself, and supports usages other than vulnerability scanning (e.g SBOMs, ad-hoc inventory analysis) I don't think component-detection

• should discard the binary package name
• have the API for the Name field be dependent on the current CVE security behaviour of various distros

I've proposed an alternative in #126 which is to keep both binary and source package name.