[Resources.OperatingSystem] Add a fallback mechanism for build.id

[ysolomchenko]

Changes

Add a fallback mechanism for build.id in the OS detector

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

Attention: Patch coverage is 87.50000% with 1 line in your changes missing coverage. Please review.

Project coverage is 77.20%. Comparing base (71655ce) to head (feed0e6).
Report is 408 commits behind head on main.

Files with missing lines	Patch %	Lines
...sources.OperatingSystem/OperatingSystemDetector.cs	87.50%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2047      +/-   ##
==========================================
+ Coverage   73.91%   77.20%   +3.29%     
==========================================
  Files         267        3     -264     
  Lines        9615      136    -9479     
==========================================
- Hits         7107      105    -7002     
+ Misses       2508       31    -2477     

Flag	Coverage Δ
unittests-Resources.OperatingSystem	77.20% <87.50%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...sources.OperatingSystem/OperatingSystemDetector.cs	82.25% <87.50%> (ø)

... and 269 files with indirect coverage changes

[Kielek]

What if kernelOsRelease is null? Should it be verified?

[ysolomchenko]

If kernelOsRelease is null, it should be considered a special case. In practice, kernelOsRelease would only be null if constructor used for testing explicitly sets it to null. In default scenarios, it will never be null. Therefore, I don't believe it's necessary to include a check for null in this case.