Stabilize service.instance.id on resource

service.instance.id is now stable: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/resource/service.md#service-instance

The conventions state:

Implementations, such as SDKs, are recommended to generate a random Version 1 or Version 4 RFC
4122 UUID, but are free to use an inherent unique ID as the source of
this value if stability is desirable. In that case, the ID SHOULD be used as source of a UUID Version 5 and
SHOULD use the following UUID as the namespace: 4d63009a-8d0f-11ee-aad7-4c796ed8e320.

We've been doing this for a while in an experimental capacity via ServiceInstanceIdResourceProvider, which is published as part of opentelemetry-sdk-extensions-incubator. If the incubator is on your classpath and you use autoconfigure (conditions which are both true if using the otel java agent), you've been getting service.instance.id for a while.

I am debating whether service.instance.id should be produced as part of the default resource (Resource.getDefault()), rather than via a resource detector:

• If included in Resource.getDefault() - everyone gets a service.instance.id unless you jump through hoops to remove. Similar to how everyone gets telemetry.sdk.* resource attributes.
• If included as a resource detector (and the current in development service resource detector spec suggests this should be the case), then you only get service.instance.id when using autoconfigure or declarative config.

Start by reading Resource.getDefault() and the incubator ServiceInstanceIdResourceProvider.java, then compare the linked service.instance.id convention and the in-development service resource detector spec. The issue is done only after deciding whether the attribute belongs in the default resource or detector path and documenting or implementing the chosen behavior with appropriate coverage.