Implement a way for user features to acquire OpenTelemetryInfo

[benjamin-confino]

This is linked with #32050

z/OS Connect have requested a way to get hold of OpenTelemetry objects. We have existing code that could provide this (OpenTelemetryAccessor) but it is not exposed to user features, and it has additional functionality that should not be exposed to user features. To resolve this issue a stripped down version of OpenTelemetryAccessor and OpenTelemetryInfo should be packaged as an SPI.

Checklist

• [x] Create a variant of OpenTelemetryAccessor that only provides a method for acquiring OpenTelemetryInfo and package in a SPI jar in dev.
• [x] Create a variant of OpenTelemetryInfo that does not expose a dispose() method and package it in the same SPI jar.
• [x] Expand on the javadoc as its going to be visible outside the team.
• [x] Write a FAT test that uses the SPI
• [x] Beta guard

[Azquelt]

A few questions:

• There are a few different scenarios for OTel objects, aren't there? You can have one per application, or one for the whole server. Similarly you could be trying to acquire the OTel object within the context of an application or outside of it. Can you list what you expect to happen in each case? You should probably have a test for each case.
• Are there restrictions on when a user feature can obtain the OTel object? Could there be cases where they try to acquire it before mpTelemetry has registered the start of the application?

To add to the list above:

• Create an SPI jar (for the dev directory and for publishing to maven central)

[benjamin-confino]

There are a few different scenarios for OTel objects, aren't there? You can have one per application, or one for the whole server. Similarly you could be trying to acquire the OTel object within the context of an application or outside of it. Can you list what you expect to happen in each case? You should probably have a test for each case.

	One oTel per App	One oTel per Server
Called within app contex	Return the app oTel object	Return the server oTel object
Called outside app contex	Will return a NoOp object (currently an NPE but I'm fixing this as part of an unrelated issue)	Return the server oTel object

Are there restrictions on when a user feature can obtain the OTel object? Could there be cases where they try to acquire it before mpTelemetry has registered the start of the application?

This would be legitimate if running in server scoped mode, and as per the standard OTel paradigm it returns a no-op rather than fails or imposes restrictions if called when there is no working OTel object available.