- ResourceResolver and ResourceResolverChain now have a consistent API
  with regard to method names and terminology.

- ResourceResolver and ResourceResolverChain now accept
  List<? extends Resource> instead of List<Resource> for simplified
  programmatic use.

- Improved Javadoc across the package.

- Formatted code to align with standards.

- Removed all references to ResourceUrlPathTranslator.

Issue: SPR-10933

An initial commit with expanded support for static resource handling:

- Add ResourceResolver strategy for resolving a request to a Resource
  along with a few implementations.

- Add PublicResourceUrlProvider to get URLs for client-side use.

- Add ResourceUrlEncodingFilter and
  PublicResourceUrlProviderExposingInterceptor along with initial
  MVC Java config support.

Issue: SPR-10933

Issue: SPR-11678

Issue: SPR-11646

Issue: SPR-11644

Issue: SPR-11262

This reverts commit 3474afb1.

Unfortunately this change is likely to cause issues for applications
that use regular expressions in a URI variable. I think we will have
to leave at: if there are any dots in the last segment of the
request path, regardless of whether they're in a URI var or not,
the suffix pattern match is off.

Issue: SPR-11532

Issue: SPR-11591

Revised ResizableByteArrayOutputStream as an actual subclass of ByteArrayOutputStream, and consistently applied appropriate ByteArrayOutputStream initial capacities across the codebase

Issue: SPR-11594

SessionFlashMapManager also clears the session attribute now when the given FlashMap List is empty.

Issue: SPR-11538

Issue: SPR-11548

After this change dots inside URI variables in a request mapping
pattern are ignored and no longer considered an indication that
the pattern contains a suffix itself.

Issue: SPR-11532

In addition to the target parameter values (SPR-9657), the target
parameter names must also be decoded to be able to match
them to the parameter names of incoming requests.

Issue: SPR-11504

AbstractDispatcherServletInitializer now adds a unique suffix to a
filter name if it fails to register it.

Issue: SPR-11493

Prior to this commit, one had to provide her own
RequestMappingHandlerMapping instance (i.e extend
WebMvcConfigurationSupport and override the requestMappingHandlerMapping
method) in order to customize path matching properties on that bean.

Since SPR-10163, XML config users can do that using the
<mvc:path-matching/> XML tag. This commit adds the same feature to MVC
Java config with a PathMatchConfigurer.

Issue: SPR-11486

Issue: SPR-11484

Issue. SPR-11428

Issue. SPR-11428

Issue. SPR-11428

Restored original detectHandlerMethods call chain for backwards compatibility with custom subclasses (such as in Spring Integration)

Issue: SPR-11426

Issue: SPR-11425

Just implementing common custom subclass behavior out-of-the-box...

Issue: SPR-11417

Issue: SPR-11413

Also throws IllegalStateException instead of ServletException now, consistent with other Spring MVC classes.

Issue: SPR-11411

Before this change MvcUriComponentsBuilder could not create a
UriComponentsBuilder for methods where the mapping has a URI variable
and no matching method argument for it.

For example a URI variable may be in the type-level mapping but not
all methods may have an @PathVariable argument for it.

This fix addresses the shortcoming such that MvcUriComponentsBuilder
expands the method argument values available to it and leaves remaining
URI variables to be further expanded via UriComponents.expand().

Issue: SPR-11391

Issue: SPR-11391