Reproduce claims raised in SPR-8849

This commit introduces a test suite (Spr8849Tests) that demonstrates
the claims made in SPR-8849.

Specifically, if <jdbc:embedded-database id="xyz" /> is used to create
an embedded HSQL database in an XML configuration file and that
configuration file is imported in different sets of configuration files
that are used to load ApplicationContexts for different integration
tests, the embedded database will be initialized multiple times using
any nested <jdbc:script /> elements. If such a script is used to create
a table, for example, subsequent attempts to initialize the database
named "xyz" will fail since an embedded database named "xyz" already
exists in the JVM.

As a work-around, this test suite uses a SpEL expression to generate a
random string for each embedded database instance:

  id="#{T(java.util.UUID).randomUUID().toString()}"

See the Javadoc in Spr8849Tests for further information.

Issue: SPR-8849
spring-test module now depends on junit:junit-dep

The junit:junit Maven artifact includes a bundled version of hamcrest
core. For projects that depend on later versions of hamcrest this causes
significant issues in terms of dependency management.

The spring-test module now depends on junit:junit-dep, thus allowing
developers to better manage their test dependencies on a more fine
grained level.

Also tidied up dependency issues regarding hamcrest-core and
hamcrest-all across the build.

Issue: SPR-6966
Upgrade to Gradle 1.0 GA

Issue: SPR-9494
Require aopalliance dependency for spring-aop

A recent commit made aopalliance optional for spring-aop, while
continuing to require it for spring-tx. On review, this is probably
overly aggressive, and for convenience aopalliance should remain
required for spring-aop. There are use cases for which aopalliance is
indeed optional, but core functionality such as <aop:scoped-proxy>
should never result in a ClassNotFoundException.

This commit returns the aopalliance dependency for spring-aop to
required status, and also explicitly notes the same dependency in other
modules that compile directly against aopalliance types.

Issue: SPR-9501
Raise RestClientException for unknown status codes

HttpStatus cannot be created with an unknown status code. If a server
returns a status code that's not in the HttpStatus enum values, an
IllegalArgumentException is raised. Rather than allowing it to
propagate as such, this change ensures the actual exception raised is
a RestClientException.

Issue: SPR-9406
Allow parsing of media types with single-quotes

Previously MediaType could only parse double-quoted parameters without
raising an IllegalArgumentException. Now parameters can also be
single-quoted.

Issue: SPR-8917
Merge pull request #93 from maxcom/SPR-8917

* SPR-8917:
  Allow parsing of media types with single-quotes
Add splitIndex Javadoc option to the root project

Splits the very large index page with all classes into individual pages
organized by first letter.

Issue: SPR-4984
Merge pull request #95 from rstoyanchev/SPR-4984

* rstoyanchev/SPR-4984:
  Add splitIndex Javadoc option to the root project
Minor Javadoc fix

Issue: SPR-9513
Minor fix in Javadoc for RequestMapping

Issue: SPR-9483
Merge pull reqest #92 from DavidBiesack/master

* DavidBiesack-master:
  Minor fix in Javadoc for RequestMapping
BeanFactory for configuring a Jackson ObjectMapper

The BeanFactory makes it easier to configure a customized Jackson
ObjectMapper (for example enable/disable certain features).
This bean factory is usually used with
MappingJacksonHttpMessageConverter or MappingJacksonJsonView.
See JavaDoc for examples.

Issue: SPR-9125
Merge pull reqest #88 from dmak/SPR-9125

* SPR-9125:
  BeanFactory for configuring a Jackson ObjectMapper
Fix typo in MessageSource reference docs

Issue: SPR-5022
Fix outdated Javadoc in the TestContext framework

Fixed outdated Javadoc regarding support for 'annotated classes' in
the TestContext Framework.
Add Gradle task for building zip with dependencies

Some Spring Framework users and teams cannot use transitive dependency
management tools like Maven, Gradle and Ivy. For them, a `distZip` task
has been added to allow for creating a Spring Framework distribution
from source that includes all optional and required runtime
dependencies for all modules of the framework.

This 'dist-with-deps' zip is not published to the SpringSource
repository nor to the SpringSource community download page. It is
strictly an optional task introduced as a convenience to the users
mentioned above.

Detailed instructions for building this zip locally have been added to
the wiki and the README has been updated with a link to that new doc.

Issue: SPR-6575
Reformat and add links to README

The readme is heavy on links and hard to read in source form when using
typical inline Markdown links. The following changes have been made to
increase readability.

 - Wrap lines at 80 characters
 - Use 'implicit link name' shortcut syntax as described at [1]
 - Add link to 'spring-mvc' Stack Overflow tag as well
 - Add link to new 'lifecycle of an issue' wiki doc

[1]: http://daringfireball.net/projects/markdown/syntax
Infer return type of parametrized factory methods

Currently, if a factory method is parameterized and the corresponding
variable types are declared on the method itself instead of on the
enclosing class or interface, Spring always predicts the return type to
be Object, even if the return type can be explicitly inferred from the
method signature and supplied arguments (which are available in the bean
definition).

This commit introduces a new resolveParameterizedReturnType() method in
GenericTypeResolver that attempts to infer the concrete type for the
generic return type of a given parameterized method, falling back to the
standard return type if necessary. Furthermore,
AbstractAutowireCapableBeanFactory now delegates to
resolveParameterizedReturnType() when predicting the return type for
factory methods.

resolveParameterizedReturnType() is capable of inferring the concrete
type for return type T for method signatures similar to the following.
Such methods may potentially be static. Also, the formal argument list
for such methods is not limited to a single argument.

 - public <T> T foo(Class<T> clazz)
 - public <T> T foo(Object obj, Class<T> clazz)
 - public <V, T> T foo(V obj, Class<T> clazz)
 - public <T> T foo(T obj)

Issue: SPR-9493
Merge pull request #97 from sbrannen/SPR-9493

* SPR-9493:
  Infer return type of parametrized factory methods