Issue: SPR-13054

Previously, the binding may have to call the getter first to retrieve the
old value of a property before actually setting it. This was guarded by
a catch block that was accidentally removed in 3d86f15a

Restore that catch block and add a test to cover it.

Issue: SPR-12805

DirectFieldAccessor now support richer NotWritablePropertyException
content, including dedicated error message and possible matches.

Issue: SPR-13053

Prior to this commit, the `ResourceHttpRequestHandler` would not
properly handle HTTP requests to **directories contained in JARs**.
This would result in HTTP 500 errors, caused by `FileNotFoundException`
or `NullPointerException`.

This can be tracked to webapp ClassLoader implementations in servlet
containers:
* in Jetty9x, fetching a directory within a JAR as a `Resource` and
getting its InputStream work fine, but attempting to `close()` it
results in a NullPointerException as the underlying stream is null.
* In Tomcat6x, one cannot fetch an InputStream for the same `Resource`
as it throws a FileNotFoundException.

This change adds more try/catch clauses and catches more Exception so as
to result in HTTP 200 OK responses instead of server errors. While this
is inconsistent because the same code path would result in HTTP 404 with
existing directories on the file system, there's no other simple way to
make those checks for resources contained in JARs.

Issue: SPR-12999

`BeanWrapperImpl` and `DirectFieldAccessor` are two
`ConfigurablePropertyAccessor` implementations with different features
set.

This commit harmonizes the two implementations to use a common base class
that delegates the actual property handling to the sub-classes:

* `BeanWrapperImpl`:  `PropertyDescriptor` and introspection utilities
* `DirectFieldAccessor`: reflection on `java.lang.Field`

Issues: SPR-12206 - SPR-12805

Issue: SPR-13045

Issue: SPR-13035

* patch-1:
  Fix number parsing of @Scheduled attributes

See gh-801

Previously, a Bean implementing `AutoCloseable` (or `Closeable`) was
always destroyed regardless of its bean definition. In particular, the
documented way of disabling the destruction callback via an empty String
did not work.

AutoCloseable beans are now treated pretty much as any other bean: we
still use the presence of the interface to optimize the check of a
destroy method and we only auto-discover the method name to invoke if
the inferred mode is enabled.

Issue: SPR-13022

Includes support for currency detection with @NumberFormat.

Issue: SPR-12209

Issue: SPR-12926

Issue: SPR-12323

Issue: SPR-12673

Prior to this commit, WebJars users needed to use versioned links within
templates for WebJars resources, such as `/jquery/1.2.0/jquery.js`.
This can be rather cumbersome when updating libraries - all references
in templates need to be updated.

One could use version-less links in templates, but needed to add a
specific MVC Handler that uses webjars.org's webjar-locator library.
While this approach makes maintaing templates easier, this makes HTTP
caching strategies less optimal.

This commit adds a new WebJarsResourceResolver that search for resources
located in WebJar locations. This ResourceResolver is automatically
registered if the "org.webjars:webjars-locator" dependency is present.

Registering WebJars resource handling can be done like this:

```java
@Override
protected void addResourceHandlers(ResourceHandlerRegistry registry) {
  registry.addResourceHandler("/webjars/**")
          .addResourceLocations("classpath:META-INF/resources/webjars")
          .resourceChain(true)
              .addResolver(new WebJarsResourceResolver());
}
```

Issue: SPR-12323

polish

Issue: SPR-12741

Prior to this commit, registering `HandlerInterceptor`s using the
`InterceptorRegistry` would not guarantee their order of execution. In
fact, `HandlerInterceptor`s would always be executed before
`MappedInterceptor`s.

This change makes `MappedInterceptor` implement the `HandlerInterceptor`
interface, in order to register all interceptors in a single ordered
list. The order of execution of interceptors is now guaranteed in the
`HandlerExecutionChain` built by `AbstractHandlerMapping`.

Issue: SPR-12673

Remove unused imports

Includes an ajc downgrade to AspectJ 1.8.5 due to Gradle 2.4 not working on JDK 9.

Issue: SPR-13042

Issue: SPR-12893

This commit introduces support for OkHttp
(http://square.github.io/okhttp/) as a backing implementation for
ClientHttpRequestFactory and AsyncClientHttpRequestFactory.

Issue: SPR-12893

Issue: SPR-13043

Issue: SPR-13032

Issue: SPR-13033

MvcUriComponentsBuilder::fromMethodCall creates wrong URLs with derived
controller classes. The @RequestMapping of the declaring class of the
method that is called is used instead of the @RequstMapping of the
given controller class.

https://jira.spring.io/browse/SPR-13033

After this change CorsProcessor has a single processRequest method and
it also explicitly deals with a null CorsConfiguration, which for
pre-flight requests results in a rejection while for simple requests
results in no CORS headers added.

The AbstractHandlerMapping now uses a LinkedHashMap to preserve the
order in which global patterns are provided.

Issue: SPR-12702

Issue: SPR-13038

ByteBufferConverter also defensively returns the rewind result now.

Issue: SPR-13031

Issue: SPR-13024

Issue: SPR-12933

In order to simplify configuration of the SpringMethodRule and to ensure
that the correct TestContextManager is always retrieved for the
currently executing test class, this commit introduces a static
TestContextManager cache in SpringClassRule.

In addition, since it is not foreseen that SpringClassRule and
SpringMethodRule should be able to be subclassed, their internal methods
are now private instead of protected.

Issue: SPR-7731