Polish ReflectiveMethodResolver and unit tests

 - Update Javadoc
 - Fix whitespace errors (tabs v. spaces, trailing spaces)
 - Break at 90 chars where sensible
 - Remove dead test code
 - Fix generics warnings, remove @SuppressWarnings
Allow customization of SpEL method resolution

This change introduces a protected ReflectiveMethodResolver#getMethods,
allowing subclasses to specify additional static methods not
declared directly on the type being evaluated. These methods then become
candidates for filtering by any registered MethodFilters and ultimately
become available within for use within SpEL expressions.

Issue: SPR-9038
SPR-9079 Don't check for "POST" multipart request method arg resolvers
Merge pull request #21 from aclement/spr9038
SPR-9075 Add fromRequestUri() methods to ServletUriComponentsBuilder
SPR-9076 Add normalize() method to UriComponents.
SPR-9077 Remove empty path segments from input to UriComponentsBuilder.
Check original beanClass in #isFactoryBean calls

This issue originates from a need in Spring Data JPA, wherein a custom
InstantiationAwareBeanPostProcessor may alter the predicted type of
FactoryBean objects, effectively preventing retrieval of those beans via
calls to #getBeansOfType(FactoryBean.class).

The reason for this "masking effect" is that prior to this change, the
implementation of AbstractBeanFactory#isFactoryBean considered only the
"predicted type" returned from #predictBeanType when evaluating
assignability to FactoryBean.class

The implementation of #isFactoryBean now ensures that not only the
predicted bean type is considered, but also the original bean
definition's beanClass (if one is available).

Issue: SPR-8954
Fix method equality bug in ExtendedBeanInfo

A number of users reported issues with comparing method identity vs
equivalence when discovering JavaBeans property methods in
ExtendedBeanInfo.

This commit updates the implementation to consistently use '.equals()'
instead of '=='.

Issue: SPR-8079, SPR-8347
SPR-9085 Correct typo.
Respect @Configuration(value) for @Imported classes

Prior to this commit, @Configuration classes included via @Import (or
via automatic registration of nested configuration classes) would
always be registered with a generated bean name, regardless of whether
the user had specified a 'value' indicating a customized bean name, e.g.

    @Configuration("myConfig")
    public class AppConfig { ... }

Now this bean name is propagated as intended in all cases, meaning that
in the example above, the resulting bean definition of type AppConfig
will be named "myConfig" regardless how it was registered with the
container -- directly against the application context, via component
scanning, via @Import, or via automatic registration of nested
configuration classes.

Issue: SPR-9023
Better support for @SessionAttributes in clustered environments

A list of "known" session attributes (listed in @SessionAttributes)
was gradually built as attributes get added to the model. In a
failover scenario that knowledge is lost causing session attributes
to be potentially re-initialized via @ModelAttribute methods.

With this change @SessionAttributes listed by name are immediately
added to he list of "known" session attributes thus this knowledge
is not lost after a failover. Attributes listed by type however
still must be discovered as they get added to the model.
Relax -aspects dependence on -test (compile=>test)

The spring-aspects Maven pom had an incorrect compile-scoped dependence
on spring-test. In fact, spring-aspects only uses spring-test in its
unit tests. The pom has been updated accordingly, meaning that use
of spring-aspects in Maven-based applications will no longer require
spring-test on the classpath at runtime.

ivy.xml metadata did not need updating, as it was already correct.

This change is only necessary on the 3.1.x line; in 3.2.x (master) Maven
poms are generated automatically from Gradle dependency metadata, which
is also already correct.

Issue: SPR-9048
Optimize ApplicationContextInitializer handling

 - Perform early check whether any ACI classes have been declared and
   exit immediately if not, avoiding any other processing

 - Polish method names in ContextLoaderTests

Issue: SPR-8991
Allow ACI classes access to servlet context params

Prior to this commit, StandardServletEnvironment's servlet context
PropertySource remained stubbed out until it the ServletContext became
available and could be replaced during the refresh() of its enclosing
WebApplicationContext. This behavior is acceptable in most cases.
However, if the user has declared an ApplicationContextInitializer that
attempts to access servlet context-params via the Environment API, this
result in a kind of 'false negative', i.e. the context-param key and
value are actually present in the ServletContext, but the PropertySource
representing servlet context params is still a stub at this point,
meaning that it returns an empty result in all cases.

With this change, WebApplicationContextUtils#initServletPropertySources
is invoked eagerly by the ContextLoader if any ACI classes have been
declared. This swaps out the servlet context property source stub for
the real thing just in time for ACIs to use it if necessary.

Extra guard logic has been added to #initServletPropertySources to
ensure idempotency -- once the stub has been replaced, the method
never attempts the replacement again, e.g. during the normal context
refresh() when this method will be called again.

Issue: SPR-8991
Allow SELECT statements in ResourceDatabasePopulator

ResourceDatabasePopulator is a component that underlies the database
initialization support within Spring's jdbc: namespace, e.g.:

    <jdbc:initialize-database data-source="dataSource">
        <jdbc:script execution="INIT" location="classpath:init.sql"/>
    </jdbc:initialize-database>

Prior to this commit, ResourceDatabasePopulator#executeSqlScript's use
of Statement#executeUpdate(sql) precluded the possibility of SELECT
statements because returning a result is not permitted by this method
and results in an exception being thrown.

Whether this behavior is a function of the JDBC specification or an
idiosyncracy of certain implementations does not matter as the issue
can be worked around entirely. This commit eliminates use
of #executeUpdate(sql) in favor of #execute(sql) followed by a call
to #getUpdateCount, effectively allowing any kind of SQL statement to
be executed during database initialization.

Issue: SPR-8932
Merge pull request #26 from trisberg/improved-RDP
Fix single quote parsing in NamedParameterUtils

Prior to this change, single quotes were incorrectly parsed by
NamedParameterUtils#parseSqlStatement, resulting in incorrect parameter
counts:

    ParsedSql sql = NamedParameterUtils
            .parseSqlStatement("SELECT 'foo''bar', :xxx FROM DUAL");
    assert sql.getTotalParameterCount() == 0 // incorrect, misses :xxx

That is, presence of the single-quoted string caused the parser to
overlook the named parameter :xxx.

This commit fixes the parsing error such that:

    ParsedSql sql = NamedParameterUtils
            .parseSqlStatement("SELECT 'foo''bar', :xxx FROM DUAL");
    assert sql.getTotalParameterCount() == 1 // correct

Issue: SPR-8280
Merge pull request #27 from trisberg/parameter-parsing
Tighten FlashMapManager for use with alternative storage options

Ensure that both FlashMapManager methods - the one invoked at the
start of a request and the one invoked before a redirect, update
the underlying storage fully since it's not guaranteed that both
will be invoked on any given request.

Also move the logic to remove expired FlashMap instances to the
metohd invoked at the start of a request to ensure the check is
made frequently enough.

SPR-8997