Support constructor binding on 3rd party classes

We had a first attempt in #23172 that we decided to revert due to a number of inconsistencies the proposal brings.

Using a declarative model as proposed in #23172 means that we need to figure out whether the user expects the binder to use constructor binding or regular JavaBean conventions. Ignoring that a Kotlin data class (or Java record) could provide us extra metadata, we didn't manage to find an acceptable solution for @EnableConfigurationProperties.

Binding to 3rd party classes so far has been a niche. The way to do this is by declaring a @Bean method with @ConfigurationProperties. For a constructor-based approach, this isn't possible but we could provide a shortcut where one needs to inject a component we'd register in the context, something like:

@Bean
public MyCustomObject myCustomObject(SomeBinder binder) {
    return binder.bind(MyCustomObject.class, "example.acme");
}

The definition above would bind MyCustomObject using the example.acme namespace. Rather than a Class you may provide a supplier for the instance and/or a mode to determine how you want the binder to operate.

Doing things this way means that the annotation processor won't be able to easily detect that it has to generate properties for this. Considering the metadata isn't going to contain default values and description anyway (since the code sits in a different module), this can be considered as a limitation (and one of the reason we may want to keep this niche).

Start by reviewing the reverted proposal in #23172 and the current @Bean method with @ConfigurationProperties approach described here. Compare the available binder options for constructor-based third-party classes, including a Class or supplier and binding mode. Done means an agreed API and behavior, with the annotation-processor metadata limitation explicitly addressed.