FrameworkPortlet properly initializes StandardPortletEnvironment's property sources

Issue: SPR-11816
Introduce annotation to execute SQL scripts in the TCF

Prior to this commit, it was possible to execute SQL scripts
programmatically via ResourceDatabasePopulator, JdbcTestUtils, and
ScriptUtils. Furthermore, it was also possible to execute SQL scripts
declaratively via the <jdbc> XML namespace. However, it was not
possible to execute SQL scripts declaratively on a per test class or
per test method basis.

This commit makes it possible to declaratively configure SQL scripts
for execution in integration tests via annotations that can be declared
at the class or method level. Details follow.

 - Introduced a repeatable @DatabaseInitializer annotation that can be
   used to configure SQL scripts at the class or method level with
   method-level overrides. @DatabaseInitializers serves as a container
   for @DatabaseInitializer.

 - Introduced a new DatabaseInitializerTestExecutionListener that is
   responsible for parsing @DatabaseInitializer and
   @DatabaseInitializers and executing SQL scripts.

 - DatabaseInitializerTestExecutionListener is registered by default in
   abstract base test classes as well as in TestContextBootstrapper
   implementations.

 - @DatabaseInitializer and @DatabaseInitializers may be used as
   meta-annotations; however, attribute overrides are not currently
   supported for repeatable annotations used as meta-annotations. This
   is a known limitation of Spring's AnnotationUtils.

 - The semantics for locating SQL script resources is consistent with
   @ContextConfiguration's semantics for locating XML configuration
   files. In addition, a default SQL script can be detected based
   either on the name of the annotated class or on the name of the
   annotated test method.

 - @DatabaseInitializer allows for specifying which DataSource and
   PlatformTransactionManager to use from the test's
   ApplicationContext, including default conventions consistent with
   TransactionalTestExecutionListener and @TransactionConfiguration.

 - @DatabaseInitializer supports all of the script configuration options
   currently supported by ResourceDatabasePopulator.

 - @DatabaseInitializer and DatabaseInitializerTestExecutionListener
   support execution phases for scripts that dictate when SQL scripts
   are executed (i.e., before or after a test method).

 - SQL scripts can be executed within the current test's transaction if
   present, outside of the current test's transaction if present, or
   always in a new transaction, depending on the value of the boolean
   requireNewTransaction flag in @DatabaseInitializer.

 - DatabaseInitializerTestExecutionListener delegates to
   ResourceDatabasePopulator#execute to actually execute the scripts.

Issue: SPR-7655
Merge pull request #557 from sbrannen/SPR-7655

Introduce annotation to execute SQL scripts in the TCF
Update regarding tested versions of Eclipse & STS
Polish Eclipse import script
Polish Javadoc for TestContextTransactionUtils
Reference manual polishing
Merge pull request #558 from VasylTretiakov/patch01

* patch01:
  Reference manual polishing
ConfigurationClassParser falls back to ASM-based resolution of member classes in case of NoClassDefFoundError

Issue: SPR-11844
Support for Java 8's java.util.Optional at injection points

Issue: SPR-11833
Support for java.util.Optional within ObjectFactory/Provider

Includes support for arbitrary deep nesting levels in DependencyDescriptor's getDependencyType() and MethodParameter's getNestedParameterType().

Issue: SPR-11833
Update Javadoc on SockJS client library URL

Issue: SPR-11766
Improve no content handling in MockHttpServletRequest

Issue: SPR-11764
Fix issue with RequestBody(required=true)

Issue: SPR-11828
AbstractAutowireCapableBeanFactory's getTypeForFactoryBean considers FactoryBean<Object> declarations as non-indicative (just like raw declarations)

Issue: SPR-11842
Support Groovy Markup templating in Spring MVC

This commit adds support for Groovy templating, available as of
Groovy 2.3.1.

To enable this, one should create a new GroovyMarkupViewResolver
and a new GroovyMarkupConfigurer Beans in their application context.

Issue: SPR-11789