Issue: SPR-13192

AllEncompassingFormHttpMessageConverter registers MappingJackson2XmlHttpMessageConverter and GsonHttpMessageConverter (for consistency with RestTemplate and WebMvcConfigurationSupport)

Issue: SPR-13240

When using an Apache Http components based infrastructure, a null header
value is handled as the empty string. The exact same infrastructure using
HttpURLConnection generates a header with no colon. This is actually not
proper HTTP and some components fail to read such request.

We now make sure to call HttpURLConnection#addRequestProperty with the
empty String for a null header value.

Issue: SPR-13225

Issue: SPR-13191

Issue: SPR-13212

Browsers like Chrome or Safari include an Origin header for same-origin
POST/PUT/DELETE requests, not only for cross-origin requests.

Before this commit, these same-origin requests would have been detected
as potential cross-origin requests, and rejected if the same-origin domain
is not part of the configured allowedOrigins.

This commit avoid to reject same-origin requests by reusing the logic
introduced in Spring 4.1 for detecting reliably Websocket/SockJS
same-origin requests with the WebUtils.isValidOrigin() method. This
logic has been extracted in a new WebUtils.isSameOrigin() method.

Issue: SPR-13206

This commit introduces the following changes:
 - The new CorsConfigurationMapping class allows to share the mapped
   CorsConfiguration logic between AbstractHandlerMapping and CorsFilter
 - In AbstractHandlerMapping, the Map<String, CorsConfiguration>
   corsConfiguration property has been renamed to corsConfigurations
 - CorsFilter allows to process CORS requests at filter level, using any
   CorsConfigurationSource implementation (for example
   CorsConfigurationMapping)

Issue: SPR-13192

Issue: SPR-13193

When using Appache Commons FileUpload, multi parts with binary data
(i.e. that are not actual files) are saved and then accessed as
String request parameters.

Before this change however the RequestPartServletServerHttpRequest
used a fixed encoding (UTF-8) while the parsing code in
CommonsFileUploadSupport/Resolver used the encoding from the
content-type header, or the request, or the FileUpload component.

This change does a best effort to determine the encoding of the
request parameter using a similar algorithm as the parsing side
that should work the same unless the encoding comes from the
FileUpload component which is not accessible.

Issue: SPR-13096

Issue: SPR-13200

Issue: SPR-11861

Issue: SPR-13194

XML parsing tests pass on non-English locales now, plus a revised exception message and some minor polishing

Issue: SPR-13136
(cherry picked from commit 38b8262e)

Issue: SPR-13136

Issue: SPR-13004

This split avoids a package tangle (between core and core.annotation) and also allows for selective use of raw annotation exposure versus synthesized annotations, with the latter primarily applicable to web and message handler processing at this point.

Issue: SPR-13153

Prior to this commit, `HttpEntityMethodProcessor` would rely on
`ServletWebRequest` to process conditional requests and with incoming
`"If-Modified-Since"` / `"If-None-Match"` request headers.

This approach is problematic since in that class:

* response is wrapped in a `ServletServerHttpResponse`
* this wrapped response does not write response headers right away
* `ServletWebRequest.checkNotModified` methods can't apply their
logic with incomplete response headers

This solution adds some minimal code duplication and applies
the conditional request logic within the Processor.

A possible alternative would be to improve the
`ServletServerHttpResponse$ServletResponseHttpHeaders` implementation
with write methods - but this solution would only work for Servlet 3.x
applications.

Issue: SPR-13090

Issue: SPR-12938

Issue: SPR-12501

Previous Jackson versions do not serialize polymorphic collections correctly
when the type is specified.

Issue: SPR-12811

This commit introduces the following changes:
 - In AbstractMessageConverterMethodProcessor, the type aware variant of
   canWrite() is now called when the converter implements
   GenericHttpMessageConverter.
 - The Javadoc has been updated in GenericHttpMessageConverter to make it clear
   that the type aware canRead() and canWrite() methods should perform the same
   checks than non type aware ones.
  - AbstractGenericHttpMessageConverter now implements default type aware
    canRead() and canWrite() methods than just call the non type aware variants.
    Due to this, if subclasses just override the non type aware variants,
    they still have the right behavior.

Issue: SPR-13161

This commit adds canWrite() and write() methods to the
GenericHttpMessageConverter interface. These are type aware variants
of the methods available in HttpMessageConverter, in order to keep
parametrized type information when serializing objects.

AbstractMessageConverterMethodProcessor now calls those type aware
methods when the message converter implements GenericHttpMessageConverter.

AbstractJackson2HttpMessageConverter and GsonHttpMessageConverter uses
these new methods to make @ResponseBody method return type available
for type resolution instead of just letting the JSON serializer trying
to guess the type to use from the object to serialize.

Issue: SPR-12811

- Simplified "check" algorithms in CorsConfiguration

- Improved robustness of setter methods in CorsConfiguration in order to
  avoid attempts to modify immutable lists

- Improved CORS documentation and fixed typo

- Introduced constants in CorsConfiguration

- Removed auto-boxing in CorsRegistration

Issue: SPR-11193

Before this change HandlerMethodReturnValueHandler's were invoked in a
specific order (type-based, annotation-based, custom). However handlers
that deal with asynchronous return value handling need to always be
considered first. This affects custom handlers in particular since they
are normally ordered last.

This change introduces an AsyncHandlerMethodReturnValueHandler
sub-interface with a single method to determine if the return value is
asynchronous and if it is to look for a matching handler only among
those that are of type AsyncHandlerMethodReturnValueHandler.

Issue: SPR-13083

Issue: SPR-13078

Before this change a missing path variable value resulted in a 400
error where in fact the error is due to a mismatch between the
declared @PathVariable and the URI template, i.e. a 500 error.

This change introduced a MissingPathVariableException as a sub-class
of ServletRequestBindingException (the exception previously thrown)
and results in a response status code of 500 by default.

Issue: SPR-13121

This is a rework of 71783c5d for SPR-12540 for the async extension that
was not merging the internal RequestConfig as it should.

Issue: SPR-13125

Issue: SPR-13129

- origin --> origins
- method --> methods
- constants are now actually constant (i.e., static final)