Reject conditional `@EnableScheduling` / `@EnableCaching` declarations that rely on the `REGISTER_BEAN` phase

Minimal example reproducing the problem: https://github.com/klach-ocado/enablescheduling-configurationphase-issue

• AaaUnrelatedAutoConfiguration is where @EnableScheduling annotation was added, or (another case, when @EnableScheduling was already there) where existing conditions were collapsed to a single @Conditional.
• TriggeringAutoConfiguration (before = TriggeredAutoConfiguration.class) registers TriggeringBean.
• TriggeredAutoConfiguration depends on TriggeringBean being registered, and has @EnableScheduling.

Normally those classes are in separate modules, TriggeringAutoConfiguration is in a module that is an extension to the module with TriggeredAutoConfiguration, no other relations.

What is known already?

There is an issue that @EnableScheduling annotation added to a seemingly unrelated class (AaaUnrelatedAutoConfiguration),
or collapsing existing conditions in an unrelated class to a single @Conditional
causes existing (and working previously) @AutoConfiguration-s with @Conditional with ConfigurationPhase.REGISTER_BEAN
(e.g. @ConditionalOnBean) being skipped.

AaaUnrelatedAutoConfiguration class has comments for possible changes in the code showing that it's indeed that class that caused problems.

There of course are other options, like in TriggeredAutoConfiguration moving @ConditionalOnBean from the class to the @Bean method
but let's assume we don't want @EnableScheduling being activated unnecessarily.

Similar issues:

• https://github.com/spring-projects/spring-boot/issues/14018
• https://github.com/spring-projects/spring-framework/issues/21690

What enhancement is suggested?

Rather than introducing changes to the condition handling for configuration classes, or to the logic of @Import annotation (used underneath of @EnableScheduling),
maybe it could be possible to add some validation for @EnableScheduling annotation?
Among common @Enable* annotations, also @EnableCaching may be worth to protect, other ones are less likely to be used with REGISTER_BEAN phase.

I consider a protection similar to this one: https://github.com/spring-projects/spring-framework/issues/23206
(does not have to be so sophisticated),
or at least some warning in logs (but typically only org.springframework.boot.autoconfigure logger is enabled by users, which may not cover that).

Rationale: Those are common annotations, and user does not expect that e.g. collapsing existing conditions to a single @Conditional
in one class can accidentally cause skipping completely unrelated @AutoConfiguration-s.

Start by running the minimal reproducer linked in the issue and compare the behavior with and without the @EnableScheduling declaration in AaaUnrelatedAutoConfiguration. Then trace how @EnableScheduling and @EnableCaching interact with REGISTER_BEAN conditions, and define a validation or warning whose completion is demonstrated by preventing or clearly reporting the reproduced skipped auto-configuration.