SPR-9060 Revise HTTP Session based FlashMapManager implementation.

The "default" FlashMapManager implementation added in 3.1 was invoked
after the redirect, which is too late in cases where the HTTP session
has not been yet been created since as the response is committed.

This change corrects the issue and makes other improvements to the
FlashMapManager implementation such as extracting a base
AbstractFlashMapManager class and making it easier for other
implementations to be added (for example cookie-based).
Merge branch '3.1.x'

Conflicts:
	spring-webmvc/src/main/java/org/springframework/web/servlet/support/DefaultFlashMapManager.java
	spring-webmvc/src/test/java/org/springframework/web/servlet/support/DefaultFlashMapManagerTests.java
Remove global 'clean' from import-into-eclipse.sh

User may already have run `gradle build` successfully. This change
ensures that we do not unnecessarily remove these output directories
in order to avoid forcing the user to rebuild.
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.
Remove javabuilder from spring-aspects .project

Previously, the build script was configured to add ajbuilder to the set
of Eclipse/STS build commands, meaning that both javabuilder and
ajbuilder would be present for spring-aspects. This causes unpredictable
behavior, as these two builders compete with each other. As ajbuilder is
a functional superset of javabuilder, this commit ensures that only the
former is present for spring-aspects' .project file.

Also removed warning language in import-into-eclipse.sh about
spring-aspects failing after adding Git support, as this intermittent
problem was almost certainly an artifact of the situation described
above.
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