How should AutoConfigurationCustomizer work when file configuration is used

[jack-berg]

AutoConfigurationCustomizer provides a very useful escape hatch allowing extension of autoconfigure with programmatic configuration when env vars / system properties do not suffice.

#6575 adds support to customize the parsed configuration model, and this is useful, but there still might be instances where the configuration model does not fully represent the set of configuration options which are available via programmatic config.

We're likely to need a way to restore this escape hatch in file configuration.

We could support the AutoConfigurationCustomizer SPI, but there are some drawbacks:

• AutoConfigurationCustomizer instances would be pulling double duty, working in both file configuration and non-file configuration scenarios. This may cause issues as implementations try to customize the SDK installation in ways that don't make sense with file configuration. For example, what does AutoConfigurationCustomizer#addPropertiesSupplier do in a file configuration scenario?
• File configuration's StructuredConfigProperties property holder is different than the ConfigProperties property holder used in AutoConfigurationCustomizer, and it will be hard to resolve the differences in a way that makes sense.

We could introduce a new FileConfigurationCustomizer SPI with similar capabilities, with:

• Similar APIs as AutoConfigurationCustomizer, but with StructuredConfigProperties instead of ConfigProperties
• Removal of any AutoConfigurationCustomizer APIs which don't make sense in a file configuration context (i.e. #addPropertiesCustomizer)
• Add callback for customizing the configuration model and solve Add ability to programmatically customize configuration model when otel.experimental.config.file is set #6575 at the same time