feat: Scaffold out declarative config

[thompson-tomo]

This is the first stage to adding declarative config for tracing.

It is focussed on ensuring the trace provider is responsible for managing all children ie span processors.

[github-actions]

👋 This pull request has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this pull request will be closed eventually by the stale bot

[mwear]

Sorry I have been slow to look at the declarative config PRs. I just reviewed #2161.

Is the idea that SDK.configure becomes the thing that reads the config file? Right now it calls parse(ENV.fetch('OTEL_CONFIG_FILE', '')) but parse returns an empty Config, so setting that variable has no effect yet. I am trying to work out whether you are proposing this as the entry point instead of #2161, or whether the SDK-side pieces are the real target here, span_processors: on the TracerProvider constructor and injectable sampler/limits. Those look useful either way.

In any case, it looks like we have two approaches to consider. We should probably discuss how we would like to move forward in #2127.

[thompson-tomo]

The idea was that when you call parse if the parameter was nil/empty it would return a top level config object with no values set, these nil properties can be passed to the initializers/constructors and that triggers the load from env. Whereas if a file was read the env load wouldn't be triggered.

Note i didn't implement the file parsing etc but that can be hooked up to the parse and ideally is seperate package.

My focus was on the sdk interactions to make it easier to add declarative config and providing a path to avoiding dedicated logic for every plugin and providing a pathway to scale with additional custom plugins as supported by declarative config.