Support declarative configuration

[jack-berg]

When declarative config is used, AutoConfigureUtil.getConfig(AutoConfiguredOpenTelemetrySdk) returns null.

This adjusts all calls to this method to be able to accommodate the null response.

Introduces StructuredConfigPropertiesBridge, which implements ConfigProperties when structured config is used and reads agent / instrumentation configuration from the YAML source. See comment for more details.

[jack-berg]

StructuredConfigPropertiesBridge is my proposal for how we keep a sane configuration story in the agent / instrumentation despite the SDK having either flat sys prop / env var or structured YAML configuration options.

The idea is the implement the ConfigProperties interface using a backing StructuredConfigProperties instance, and have special logic to determine how the [standard java agent](https://opentelemetry.io/docs/zero-code/java/agent/disable/ properties map to a structured representation.

• Only properties starting with otel.instrumentation. resolve
• otel.instrumentation. refers to the node at .instrumentation.java in the declarative config data model
• To resolve a property, we take the portion after otel.instrumentation and break it up into segments. For each segment (N-1) we walk down the StructuredConfigProperties tree, and read the final segment from the resolve node.

So given the following YAML, reading configProperties.getBoolean("otel.instrumentation.common.default-enabled") resolves true:

instrumentation:
  java:
    common:
      default-enabled: true

[jack-berg]

See open-telemetry/opentelemetry-java-examples#492 for a demonstration

(Note, requires building the javaagent locally, including this PR from opentelemetry-java)