Stabilize ConfigProvider

[zeitlinger]

Is your feature request related to a problem? Please describe.

Stabilize ConfigProvider once declarative config itself is stable.

Describe the solution you'd like

getConfigProvider() is moved from ExtendedOpenTelemetry to OpenTelemetry.

Additional context

Right now, getConfigProvider() is non-null, because it's part ExtendedOpenTelemetry, which is only used in declarative config.

We have to decide what to do for non-declarative config

1. return null
2. return an empty object

• better usability over null
• based on initial discussion, it seems to make sense to have a config provider when not using declarative config, e.g. the agent currently does that

4. return an object to access config properties where applicable (in auto-config)

• could be used in contrib extensions that currently use the declarative config bridge
• not clear if this should better live in SDK or contrib

I created a PoC to show how it could work: #7960

[trask]

based on initial discussion, it seems to make sense to have a config provider when not using declarative config, e.g. the agent currently does that

one difference is that the Java agent takes major version bumps, and so we can provide backwards compatibility with system properties for now, and decide to remove that backwards compatibility in the future