fix(os): keep the fullest OS version when merging analyzer results

[DmitriyLewen]

Description

/etc/os-release and the distro-specific release file can describe the same OS with different granularity.
On CentOS 7 the former reports VERSION_ID=7, while /etc/centos-release reports 7.9.2009.
Both files are analyzed concurrently, and OS.Merge filled Name only while it was still empty, so the reported version depended on which analyzer merged first.

In practice the winner is decided by the order of the entries in the layer tar, which normally puts /etc/centos-release first.
That order is not part of the contract though.
Rebuilding the same layer with /etc/os-release moved ahead of /etc/centos-release — with the contents of every file unchanged — flips the reported version to 7 in 100% of runs.

Changes

OS.Merge now keeps the more specific version when both sources describe the same family: a new name replaces the current one when the current one is a dotted prefix of it.
CentOS is the only distribution affected in practice — Rocky, Alma, Oracle, RHEL and Fedora put the full x.y version into VERSION_ID, so their sources already agree.

Example

Before / after, same image with /etc/os-release placed first in the layer tar:

Before:

"OS": { "Family": "centos", "Name": "7" }

After:

"OS": { "Family": "centos", "Name": "7.6.1810" }

Related issues

• Discussion bug(os): Non-deterministic CentOS OS.Name across scans of the same image #11030

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[knqyf263]

Should we bump the relevant analyzer version so that old cached OS results are not reused?