Allow setting WSDL document as a Resource

Prior to this change, LocalJaxWsServiceFactory allowed specifying a WSDL
document URL. Now users may also specify a WSDL document represented as
a Spring Resource object for convenience.

Issue: SPR-9909
Merge pull request #174 from mdeinum/SPR-9909

# By Marten Deinum
* SPR-9909:
  Allow setting WSDL document as a Resource
Polish DeferredResult

After this change a DeferredResult can be set before a
DeferredResultHandler has been set.
Provide method to set async TimeoutHandler

Issue: SPR-9914
Fix split package introduced by @EnableSpringConfigured

Commit 5327a7a37d25b67ee2ae7d1ead2a3db6847767c0 moved
@EnableSpringConfigured from beans.factory.aspectj =>
context.annotation within the spring-aspects module. This resolved a
package cycle but had the side-effect of causing a "split package" [1]
problem between spring-context and spring-aspects in OSGi-based
classloader environments because the context.annotation package now
exists in both modules.

The simplest and best solution from an OSGi perspective is to relocate
@EnableSpringConfigured and its supporting SpringConfiguredConfiguration
class into a new package. This commit moves both these types into
context.annotation.aspectj, following convention with other such
"aspectj"-qualified packages in the spring-aspects module.

As with the previous move, it is presumed this change will be low-impact
as the "spring-configured" approach to domain object injection is a
niche feature to begin with, and @EnableSpringConfigured has existed in
its current location only since 3.1.2 and this change is being made in
time for 3.1.3.

[1]: http://wiki.osgi.org/wiki/Split_Packages

Issue: SPR-9811, SPR-9441
Fix package cycle in @EnableMBeanExport

Prior to this commit, @EnableMBeanExport was declared in the
jmx.export.annotation package. This makes logical sense, but
nevertheless creates a package cycle, because @EnableMBeanExport depends
on MBeanExportConfiguration which in turn depends on context.annotation
types like @Configuration, @Bean, and @Role.

context.annotation.config.MBeanExportBeanDefinitionParser, on the other
hand already has dependencies on types in jmx.support. Together, this
means that a package cycle was introduced.

The solution to this is simple: move @EnableMBeanExport and friends from
jmx.export.annotation => context.annotation. This has been the strategy
for other @Enable annotations and for the same reasons. It also makes a
kind of logical sense: just like you find <context:mbean-export> and
<context:load-time-weaver> under the context: XML namespace, so too do
you find their @Enable* counterparts under the context.annotation
namespace.

Issue: SPR-8943
Filter @Configuration classes out of LTW test

Moving @EnableMBeanExport and its MBeanExportConfiguration
@Configuration class into context.annotation caused a side effect with
ComponentScanningWithLTWTests, which component scans context.annotation
in order to test LTW behavior. Picking up MBeanExportConfiguration
without proper MBean configuration resulted in a NullPointerException
during test execution.

This commit simply filters out all @Configuration classes from the LTW
test's component-scanning directive.

Issue: SPR-8943
Rename ref doc PDF spring-{=>framework-}reference

 - Upgrade to 0.1.6 snapshot of docbook plugin

 - Fully qualify PDF artifact name as 'spring-framework-reference.pdf'
   instead of former 'spring-reference.pdf'

Issue: SPR-9598
Polish whitespace for conversion service packages
Allow PropertyResolvers to ignore unresolvable ${placeholders}

Prior to this commit, the PropertyResolver API (and therefore the
Environment API) allowed callers a choice between
 #resolvePlaceholders and #resolveRequiredPlaceholders for low-level
${placeholder} resolution. However, when calling the higher level
 #getProperty variants, users had no control over whether property
values returned with unresolvable ${placeholders} would result in an
exception or simply be passed through.

This commit introduces a #setIgnoreUnresolvableNestedPlaceholders
property via ConfigurablePropertyResolver, defaulting to false, the
value of which is respected by AbstractPropertyResolver#getProperty
method implementations. See the new test in
PropertySourcesPropertyResolverTests for usage examples.

Issue: SPR-9569, SPR-9473
Polish (major) MVC async processing interceptors

New afterTimeout and afterCompletion callbacks

afterTimeout can provide a concurrent result to be used instead of the
one that could not be set or returned on time

Interceptor exceptions cause async processing to resume treating the
exception as the concurrent result

Adapter classes for convenient implementation of the interfaces

Issue: SPR-9914
Polish (minor) RequestMappingHandlerAdapter

Revise order of fields reflecting configurable vs internal fields and
also grouping them accordingly.
Add config options for MVC async interceptors

The MVC namespace and the MVC Java config now allow configuring
CallableProcessingInterceptor and DeferredResultProcessingInterceptor
instances.

Issue: SPR-9914
Fix failing test
Delete unused imports
Configurable locales in MockHttpServletRequest

Prior to this commit the MockHttpServletRequest constructor chain set
the preferred local to Locale.ENGLISH. Furthermore, it was possible to
add additional preferred locales "in front" of ENGLISH; however, it was
not possible to delete ENGLISH from the list of preferred locales.

This commit documents the fact that ENGLISH is the default preferred
locale and makes it possible to set the list of preferred locales via a
new setPreferredLocales(List<Locale> locales) method.

Issue: SPR-9724
Update changelog

Issue: SPR-9724
Fix package cycles in spring-test

Code introduced in conjunction with SPR-5243 introduced package cycles
between the ~.test.context.web and ~.test.context.support packages. This
was caused by the fact that ServletTestExecutionListener extended
AbstractTestExecutionListener.

To address this, ServletTestExecutionListener now implements
TestExecutionListener directly.

Issue: SPR-9924
Update changelog

Issue: SPR-9593
Reduce code duplication in ContextLoaderUtils

Prior to this commit, the following two methods in ContextLoaderUtils
contained almost identical loops for traversing the test class
hierarchy:

 - resolveContextLoaderClass(Class<?>, String)
 - resolveContextConfigurationAttributes(Class<?>)

With this commit, resolveContextLoaderClass() no longer traverses the
class hierarchy. Instead, it now works directly with the resolved list
of ContextConfigurationAttributes, thereby removing code duplication.

Issue: SPR-9918