DeclarativeConfigProperties: no way to coerce types without triggering warnings

From https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/15775#discussion_r2824358976

Problem

YamlDeclarativeConfigProperties logs WARNING-level messages when a getter is called for a type that doesn't match the stored value:

WARNING: Ignoring value for key [foo] because it is Long instead of String

This means we can't build a type-coercing DeclarativeConfigProperties decorator without producing invalid warnings.

Use case

The Spring Boot starter populates OpenTelemetry's declarative config YAML from Spring's property system. Spring flattens its own YAML into key-value pairs and resolves ${} placeholders via Environment.getProperty(), which always returns String. These flat string properties are then converted back into a nested map and fed to Jackson's ObjectMapper.convertValue() to produce an OpenTelemetryConfigurationModel, which ultimately backs a YamlDeclarativeConfigProperties.

The problem is that the resulting types are inconsistent:

• Values from plain YAML (e.g. int_key: 42) are stored as their native types (Integer, Boolean, Double)
• Values resolved through Spring placeholders (e.g. int_key: ${INT_ENV:42}) arrive as String ("42")

We'd like to use a type-coercing decorator around DeclarativeConfigProperties to handle both cases transparently, but there is no way to check the actual stored type without triggering the WARNING-level logs, e.g.

• Calling delegate.getString("int_key") on a natively-typed Integer logs: "Ignoring value for key [int_key] because it is Integer instead of String"

Start by reading DeclarativeConfigProperties and YamlDeclarativeConfigProperties, then reproduce the warning from a getter whose requested type differs from the stored value. Define a way for a type-coercing decorator to inspect or retrieve values without emitting invalid WARNING messages, and verify that both native YAML values and Spring-resolved strings remain usable.