@Bean method should be always allowed to override scanned class matching its return type

[jhoeller]

Following up on #25952, we should accept an @Bean method overriding a scanned component class even when general bean definition overriding has been disabled, as long as the bean class is the same. E.g. if a CustomController class with an @RestController stereotype has been found through classpath scanning, a configuration class with an @Bean CustomController customController() method should be allowed to replace it in order to configure it in a custom way. As long as the declared return type matches the bean class, the intent is clear and there is no real risk for an accidental override.

As a consequence, this allows for declaring stereotype annotations on a class returned from an @Bean method without running into conflicts with classpath scanning. This is preferable over declaring stereotype annotations on the @Bean method itself (which is not possible due to the limited declaration of our stereotype annotations anyway) since stereotypes are meant to apply to the component class, not to the factory method or the specific instance that it creates.