Spring RequestScope breaks SpringComponentProvider

Utilizing the new(ish) `@RequestScope` annotation causes integration issues as Spring is registering multiple bean names when this annotation is present. You now end up with `originalBeanName` and `scopedTarget.originalBeanName` as bean name entries in the context for the affected class.

The specific piece that breaks is:

if (beanNames == null || beanNames.length != 1) {
LOGGER.severe(LocalizationMessages.NONE_OR_MULTIPLE_BEANS_AVAILABLE(component));
return false;
}

The application still actually works in my parituclar case as Jersey was able to use the constructor and populate the other requested beans (from spring). This is dangerous though, as it will have hidden side affects as the resources is not actually being provided by Spring when we expect to be and things like `@Transactional` or other Spring specific things will fail. This seems like a red flag as well, should something more severe be done in these cases? Fail faster?

**Note:** There is a valid workaround, just use the old `@Scope` annotation. That does not register another bean name

Start at SpringComponentProvider and inspect the beanNames check shown in the issue, then reproduce the integration behavior with @RequestScope and the older @Scope annotation. Done means the affected resource is consistently provided by Spring despite the scopedTarget bean name, with the relevant integration behavior covered by verification.

Written by the indexing model from the issue text.