Review default exclusion mechanism in AOT-optimized contexts

Right now, we do the following:

• If you implement BeanFactoryInitializationAotProcessor on a bean, it is excluded (with no way to have it back)
• If you implement BeanRegistrationAotProcessor on a bean, it is excluded by default and that can changed by overriding the isBeanExcludedFromAotProcessing method
• If you need to exclude additional components, you need to implement BeanRegistrationExcludeFilter. Such interface must be implemented with either BeanFactoryInitializationAotProcessor or BeanRegistrationAotProcessor.

The shortcut for "exclude myself" on BeanRegistrationAotProcessor is quite handy so I don't think relying only on the filter in its current form is ok. However, we should probably consider renaming the method as it doesn't exactly state what it does right now (the bean is processed and its contribution is recorded, but the bean itself won't be registered).

https://github.com/spring-projects/spring-boot/issues/32542 is another example. We have a BeanDefinitionRegistryPostProcessor that's exposed as a bean. The outcome of the post-processor (registering bean definitions) is recorded by AOT but the bean itself is contributed. This means that at runtime those bean definitions are contributed again.

Excluding them by default might not be the best option as they could potentially implement extra interface and having them excluded with no signal can be quite misleading.

Start by reading BeanFactoryInitializationAotProcessor, BeanRegistrationAotProcessor, and BeanRegistrationExcludeFilter to understand the current exclusion paths. Then review the BeanDefinitionRegistryPostProcessor example in issue #32542 and decide what behavior and method naming should be clarified or changed. Done means the exclusion mechanism has a settled, documented design.