Upgrade to Gradle 1.0-rc-3

Issue: SPR-9411
Clarify @EnableScheduling javadoc

It is now advised that destroyMethod="shutdown" should be used
on @Bean methods returning an ExecutorService.

Issue: SPR-9280
Restore serializability of HttpStatusCodeException

SPR-7591 introduced a java.nio.charset.Charset field within
HttpStatusCodeException. The former is non-serializable, thus by
extension the latter also became non-serializable.

Because the Charset field is only used for outputting the charset name
in HttpStatusCodeException#getResponseBodyAsString, it is reasonable to
store the value returned by Charset#name() instead of the actual Charset
object itself.

This commit refactors HttpStatusCodeException's responseCharset field to
be of type String instead of Charset and adds tests to prove that
HttpStatusCodeException objects are once again serializable as expected.

Issue: SPR-9273, SPR-7591
Translate SQLTimeoutException to QueryTimeoutException

SPR-7680 added QueryTimeoutException to Spring's DataAccessException
hierarchy, but did not integrate it into the
SQLExceptionSubclassTranslator; it was added mainly to accomodate users
defining their own custom exception translators.

However, it does make sense to translate any SQLTimeoutException to this
new QueryTimeoutException type, and this commit makes that change. It
does represent a slight backward-incompatibility, given that
QueryTimeoutException extends TransientDataAccessException, whereas
SQLExceptionSubclassTranslator previously returned the more specific
TransientDataAccessResourceException for any SQLTimeoutException.

It is expected that this incompatibily will be very low-impact, i.e. not
affecting many (if any) users. In any case, a major release (Spring 3.2)
is the right time to introduce such a change, and the migration path is
straightforward: any users depending on catching
TransientDataAccessResourceException in the case of query timeouts
should update those catch blocks to expect QueryTimeoutException
instead. Care should also be taken to ensure correctness of existing
catch blocks expecting TransientDataAccessException, as these blocks
will now catch QueryTimeoutException as well.

Issue: SPR-9376, SPR-7680
Fix broken javadoc link to ROME tools project

Issue: SPR-9379
Fix broken link to JavaBean customization tutorial

Issue: SPR-9408
Investigate claims made in SPR-9051 regarding transactional tests

The claim: given an integration test class that is annotated with 
@ContextConfiguration and declares a configuration class that is missing

an @Configuration annotation, if a transactional test method (i.e., one 
annotated with @Transactional) changes the state of the database then
the 
changes will not be rolled back as would be expected with the default 
rollback semantics of the Spring TestContext Framework (TCF).

TransactionalAnnotatedConfigClassWithAtConfigurationTests is a concrete 
implementation of AbstractTransactionalAnnotatedConfigClassTests that
uses 
a true @Configuration class and thereby demonstrates the expected
behavior 
of such transactional tests with automatic rollback.

TransactionalAnnotatedConfigClassesWithoutAtConfigurationTests is a 
concrete implementation of
AbstractTransactionalAnnotatedConfigClassTests 
that does NOT use a true @Configuration class but rather a 'lite mode'
configuration class (see the Javadoc for @Bean for details).

Using such a 'lite mode' configuration class results in the following:

 - Its @Bean methods act as factory methods instead of singleton beans.
 - The dataSource() method is invoked multiple times instead of once.
 - The test instance and the TCF operate on different data sources.
 - The transaction managed (and rolled back) by the TCF is not the 
   transaction that the application code or test instance uses.

Ultimately, the use of a 'lite mode' configuration class gives the false
appearance that there is a bug in the TCF (in that the transaction is
not 
rolled back); however, the transaction managed by the TCF is in fact 
rolled back.

In conclusion, these tests demonstrate both the intended behavior of the

TCF and the fact that using 'lite mode' configuration classes can lead
to 
confusing results (both in tests and production code).

Issue: SPR-9051