sdk/resource: add missing WithOS* resources

[nicbaz]

Problem Statement

At the moment only WithOSDescription and WithOSType are implemented in go.opentelemetry.io/otel/sdk/resource. If we refer to the latest tagged version of open-telemetry/semantic-conventions/docs/resource/os.md, we should also have WithOSBuildID, WithOSName and WithOSVersion.

Proposed Solution

WithOSBuildID

The documentation on how the value should be obtained per OS is self-explanatory: part of the current implementation for WithOSDescription should be re-used.

WithOSName

• For Unix/Linux, we can use the NAME value from the os-release file.
• For Windows, we can use the ProductName registry value from SOFTWARE\Microsoft\Windows NT\CurrentVersion.
• For Darwin, we can use the ProductName property value from the plist system files.

WithOSVersion

• For Unix/Linux, we can use the VERSION value from the os-release file.
• For Windows, we can use the DisplayVersion registry value from SOFTWARE\Microsoft\Windows NT\CurrentVersion.
• For Darwin, we can use the ProductVersion property value from the plist system files.

Additional Context

Regarding WithOSName and WithOSVersion, I am not 100% certain that those are right values to be used: please advise if you think it should be something else.

I stumbled upon open-telemetry/opentelemetry-collector-contrib#39941 some time ago and noticed that those APIs were missing from the SDK. For example, it uses its own implementation for OSVersion instead of the SDK implemention like it's done for OSType.

[dmathieu]

We won't be adding those in the main SDK, as those are too dependent on the platform (it's not just about OS, but the cloud platform too).
I see the azure detector already adds those.
Adding them to the other detectors would be find.
We could possibly have a baremetal (not sure about the name) detector.

[nicbaz]

Just out of curiousity, could you elaborate a bit more on what makes those specific os. attributes not valid candidates for the main SDK?
Taking host.id for example, there is a an OS-specific implementation in the main SDK, which is superseded by the Cloud-specific implementation in the contrib SDK.

[dmathieu]

First, the host namespace is not stable yet.
So adding support for more attributes in a stable SDK poses the risk of complicated migrations in the future if there are breaking changes.

host.id has an explicit spec (in the same doc above) on how it should be retrieved.

Finally, detectors are thought to be extensible. It's much more easier and modular to have smaller external detectors than everything in the same location.