Bean overriding by type uses isAutowireCandidate for matching

This commit uses the bean factory `isAutowiredCandidate` method directly
in `BeanOverrideBeanFactoryPostProcessor` to select a single match among
multiple candidates when matching by type.

The expected consequence, in most cases, is that this will delegate to
a `@Qualifier`-aware `QualifierAnnotationAutowireCandidateResolver`.
In that sense, bean overriding by-type matching is now potentially
taking Qualifier annotations or meta-annotations into account.

It also changes the way existing bean definitions are checked in case
a bean name has been specified: factory beans are now taken into account
when checking the type of an existing definition matches the expected
bean override type.

Closes gh-32822

framework-docs/modules/ROOT/pages/testing/testcontext-framework/bean-overriding.adoc

@@ -61,11 +61,11 @@ In contrast to Spring's autowiring mechanism (for example, resolution of an `@Au
 field), the bean overriding infrastructure in the TestContext framework has limited
 heuristics it can perform to locate a bean. Either the `BeanOverrideProcessor` can compute
 the name of the bean to override, or it can be unambiguously selected given the type of
-the annotated field.
+the annotated field and its qualifying annotations.
+
+Typically, the bean is selected by type by the `BeanOverrideFactoryPostProcessor`.
+Alternatively, the user can directly provide the bean name in the custom annotation.
 
-Typically, the user directly provides the bean name in the custom annotation in order to
-make things as explicit as possible. Alternatively, the bean is selected by type by the
-`BeanOverrideFactoryPostProcessor`.
 Some `BeanOverrideProcessor`s could also internally compute a bean name based on a
 convention or another advanced method.
 ====