Add support for refeshing a context for AOT processing with customized condition evaluation

[snicoll]

For Spring AOT to be more flexible, we'd like to record certain contributions without a locked-down BeanFactory. The most typical example is the handling of @Profile where we'd like to process them even though they may or may not be used at runtime.

The two immediate contenders here are: a (as much as possible) complete index for classpath scanning, and the build-time creation of CGLIB proxies.

Two things need to be improved to achieve this goals:

• The Condition contract should be expanded with the notion of AOT processing where a condition can change its behavior based this new processing. Condition evaluation should offer a configurable option where this can be turned on
• As additional bean definitions are filled in the BeanFactory bean names clash are going to be frequent. We should find a way to name those beans so that they can be inspected.

Spring AOT has a strong requirements that the classpath can't be changed. As such, @ConditionalOnClass (or any classpath-based condition) should opt-out of this new mechanism and always provide the same outcome. This will make sure we won't get a BeanDefinition in the bean factory for something that would obviously break if we tried to investigate its type.

[snicoll]

I've made some progress by tuning condition evaluation and then configuring a custom BeanNameGenerator. The integration in Spring Boot is a bit more challenging as its AutoConfigurationImportSelector is filtering auto-configuration classes early and FilteringSpringBootCondition should be adapted so that we can call an AOT variant of it.

Also OnBeanCondition is quite used as a classpath signal as well. If a bean is present, then we infer that whatever infrastructure it maps to is valid. So we need to separate this from the regular connection and prevent a match if the target type isn't on the classpath.