Custom HandlerMapping to avoid conflicts between vaadinRootMapping and resourceHandlerMapping

This is a follow-up to #602.

When no vaadin.urlMapping is defined, both vaadinRootMapping (VaadinServletConfiguration) and resourceHandlerMapping (WebMvcConfigurationSupport) will map to /* or /**.
With the vaadinRootMapping having higher precedence, the resourceHandlerMapping can no longer serve static resources.
So the idea is, instead of using the purely URL-pattern-based SimpleUrlHandlerMapping for the vaadinRootMapping, create a custom implementation, that only captures requests that we know are intended for Vaadin and ignore all others so the resourceHandlerMapping can handle them.

The general gist is: Requests are captured and directed to the VaadinServlet if

1. they have a parameter named ApplicationConstants.REQUEST_TYPE_PARAMETER with any of the known RequestTypes.
2. their URL starts with /vaadinServlet/ or /VAADIN/
3. The SessionRouteRegistry (if there is a session) or ApplicationRouteRegistry (if there isn't) have a navigation target for the URL.

[My prototype (feel free to use it) so far seemed to work pretty well.] (https://gist.github.com/Frettman/778e98ac2c4fdc4ceffc12423f929d4a) Both Vaadin and static resources living happily together in the servlet root. There was one major issue though:
When persistent sessions are restored, the VaadinSessions are still lacking some transient information, like the lock. Usually that information will be restored once the request passes through the VaadinServlet. This hasn't happened yet in the HandlerMapping. The VaadinService might not even exist yet, if the VaadinServlet hasn't received any requests yet (I suppose servlets are lazily initialized?).

Start by reviewing VaadinServletConfiguration, WebMvcConfigurationSupport, and the existing SimpleUrlHandlerMapping behavior. Trace how VaadinServlet, SessionRouteRegistry, ApplicationRouteRegistry, and VaadinService participate in request handling and session restoration. Done means Vaadin requests are routed correctly while resourceHandlerMapping still serves static resources, including after persistent sessions are restored.