Commit https://github.com/spring-projects/spring-framework/commit/2b97d6
introduced a change where the path within the DispatcherServlet is
determined with each call to ResourceUrlProvider.getForRequestUrl.

To avoid repeating that every time a URL is encoded through the
response, we now cache the result of the lookupPath determination in
ResourceUrlEncodingFilter.

Issue: SPR-12332

Issue: SPR-11905

Also respect HandlerMapping order in ResourceUrlProvider

- 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

Renamed ResourceUrlMapper to ResourceUrlGenerator and refactored it
to be configured with Resource-serving HandlerMappings as opposed to
having them detected in the ApplicationContext through the
BeanPostProcessor contact.

Renamed and polished ResourceUrlEncodingFilter to ResourceUrlFilter
and added tests.

This change splits out resource transformation out from the
ResourceResolverChain so that chain is focused entirely on resource
resolution (as its name suggests). The invocation of transformers
is left as a separate step, it uses a different (recursive)
algorithm in any case and iterates over a different set of objects.

Also ResourceResolverChain is now limited strictly to methods that
a ResourceResolver should be able to use to delegate to remaining
resolvers.

Furthermore, ResourceResolverChain now maintains an internal index
of the "current" resolver so that resolvers don't have to pass the
chain when invoking it much like a (Servlet API) FilterChain works.
If the last resolver calls the chain again, a null value is returned.