Introduce strategy for BeanInfo creation

[poutsma]

Before this commit, the CachedIntrospectionResults was hard-coded to
create ExtendedBeanInfos for bean classes. The ExtendedBeanInfo support
the JavaBeans property contract only.

This commit introduces the BeanInfoFactory, a strategy for creating
BeanInfos. Through this strategy, it is possible to support
beans that do not necessarily implement the JavaBeans contract (i.e.
have a different getter or setter style).

BeanInfoFactories are are instantiated by the
CachedIntrospectionResults, which looks for
'META-INF/spring.beanInfoFactories' files on the class path. These files
contain one or more BeanInfoFactory class names. When a BeanInfo is to
be created, the CachedIntrospectionResults will iterate through the
factories, asking it to create a BeanInfo for the given bean class. If
none of the factories support it, an ExtendedBeanInfo is created as a
default.

This commit also contains a change to Property, allowing BeanWrapperImpl
to specify the property name at construction time (as opposed to using
Property#resolveName(), which supports the JavaBeans contract only).

Issue: SPR-9677

[poutsma]

@cbeams, @jhoeller, please let me know what you think about these changes.

[philwebb]

Can you foresee any case where the existing BeanInfo needs to be accessed by the BeanInfoFactory? I am thinking perhaps BeanInfo might augment an existing BeanInfo with additional functionality (ie support traditional getters/setters in addition to some other style).

Perhaps:

public interface BeanInfoFactory {
// Can return a new BeanInfo, wrap the existing or simply return the parameter unchanged
BeanInfo getBeanInfo(BeanInfo beanInfo) throws IntrospectionException;
}

Of course this does mean that potentially beanInfo objects are created then immediately discarded.

[poutsma]

@philwebb It's an interesting proposal, but it does require the creation of a BeanInfo for each bean class before the factory is even invoked. Since Introspector#getBeanInfo() is a rather expensive method call, I think it's better to keep things as is, and let the factory choose to either create a new BeanInfo from scratch, or wrap an existing one.

[cbeams]

Thanks, this is now merged. @poutsma and @jhoeller, please see my comments at SPR-9677.