Add option to programmatically customization declarative config components, add supplementary guidance

[jack-berg]

Resolves #4583.

We've had discussions in the declarative config SIG recently about how programmatic configuration interacts with declarative config. Questions of what should take priority, and whether there should be options to programmatically customize (#4583) to address concepts which are not expressible in declarative config.

The goal here is to avoid the type of spec ambiguity which resulted SDKs having such different behavior in environment variable <> programmatic configuration intersection. Declarative configuration is green field and for a short time longer is still experimental, and so we are not bound by historical constraints.

Reading through the relevant specs, I do not think there is any ambiguity about configuration interface priority. create returns resolved top-level SDK components. If a SDK supports updating components, then the components returned by create will be subject to whatever semantics the SDK already has decided for how updates occur to SDK components programmatically created to begin with. To make this clear, I opted to add a new supplementary guidelines document to give advice to implementers without cluttering or adding more normative language.

On a related note, I thought it was pertinent to address #4583 simultaneously, but adding explicit language to allow (i.e. normative MAY) implementations of create to allow programmatic customization of SDK components as they are initialized.

cc/ @open-telemetry/configuration-approvers, @JamieDanielson, @maryliag, @pellared