Define ConfigProvider change-listener API for runtime config updates

[jackshirazi]

What are you trying to achieve?

Define a language-neutral ConfigProvider API contract that allows instrumentation
and other components to observe runtime changes to declarative configuration.

Today, declarative configuration is effectively consumed at initialization time.
To support runtime policy/config evolution (including work discussed in
OTEP: Telemetry Policy),
the configuration API needs a standardized callback/listener capability.

Proposed scope (phase 1)

Add normative API requirements for:

• listener registration/unregistration on ConfigProvider
• watched path semantics (path format + exact matching)
• callback payload semantics (path, updated config, behavior when removed/unset)
• delivery semantics (ordering/coalescing expectations)
• error handling (listener throws, provider failures)
• lifecycle and close semantics (idempotent close, behavior after close)
• behavior when provider does not support runtime notifications

Non-goals (phase 1)

• defining a full transactional/diff model for config updates
• requiring SDKs to support remote config transports/protocols
• mandating strict global ordering across multiple changed paths

Prior art / context

• Add a ConfigProvider callback for runtime instrumentation option changes opentelemetry-java#8076
• Making "methods" instrumentation dynamically updateable opentelemetry-java-instrumentation#15228

Definition of done

• Spec PR merged in specification/configuration/api.md with normative language
  for ConfigProvider change-listener behavior.

[svrnm]

@open-telemetry/configuration-approvers please take a look!