feat: Improve file_release support

[exincore]

Description

Support more operating systems for linux/file_release.rs that linux/lsb_release.rs can already detect.
Allow linux/file_release.rs to detect more information about an operating system.

Motivation

linux/file_release.rs does not yet match the functionality of linux/lsb_release.rs. Some systems which are claimed to be supported on the README are not detected where lsb_release is not present.

Todo

• Test Arch
• Support Debian
• Test Debian
• Support EndeavorOS
• Test EndeavorOS
• Support Garuda
• Test Garuda
• Support Gentoo
• Test Gentoo
• Support Manjaro
• Test Manjaro
• Test openSUSE
• Support Pop
• Test Pop
• Support Raspbian
• Test Raspbian
• Support Solus
• Test Solus
• Test SUSE (sled and sles_sap)
• Improve testing clarity and naming
• Add rolling release detection
• Add edition detection where possible
• Add codename detection where possible
• Add gathering of data from every release file instead of only the first match in order to obtain information that may be scattered between release files

[exincore]

I am finding some issues when categorizing some distributions.

There is only one Type::SUSE, but multiple variations, SUSE Linux Enterprise Server and SUSE Linux Enterprise Desktop, for example, exist which are not recorded as actual editions/variations within the os-release, but instead as different IDs (sles vs sled). To make matters worse, sles-sap has an ID=sles and the only difference is in CPE_NAME.

A similar issue appears between openSUSE Leap and openSUSE Tumbleweed, where the distinction is recorded as different IDs (opensuse-leapvsopensuse-tumbleweed`).

It is unclear to me whether they should be categorized into editions anyway, or if new Types are needed to differentiate, or if the current structure needs to be more deeply revamped in order to handle these more complex relationships between distributions, platforms (families?), etc.

Related #313 #312 #280

[stanislav-tkach]

Sorry for the delay with response and thank you very much for the pull request!

I'm also not sure in what direction to go with editions and families, so suggestions are welcome. Ideally I want to both preserve maximum information in a convenient way and not to over-complicate it. Originally I only wanted to have a string in any consistent format just to print it in logs and potentially show on a dashboard, but I understand that other people have different use cases.

By the way, there already was a discussion about families, but people voiced the same concerns: sometimes it isn't obvious how to properly categorize a specific distribution.

Additionally I think that versioning (the Version struct) is too complicated. Now I would prefer to have a simple version string with all the details because it only introduces unnecessary complexity without benefits. I don't want to bump version to 4.0 just for that, though.

[stanislav-tkach]

I also usually prefer to write tests like this, but now it stops at the first failure. Not a big issue, though.

[martintc]

My idea with families was more to deal with complications that can arise out of doing certain things on Linux platforms. As an example, comtrya is a config management tool. We have some logic that may change depending on the OS. using OS_Info for Windows and MacOS is a breeze to match on. Linux though is a pain because often what we want to do, the distro doesn't matter since what we are doing is quiet often universal to distributions. So the families was feature was a way to introduce where if I could rely on it is linux and the distro doesn't matter, the same action will work whether it is Debian or Fedora or Arch without need to create a bunch of arms to match against each distro to do the same thing.