Provide a consistent way to discover the primary DispatcherServlet's path

[snicoll]

We've introduced a DispatcherServletPathProvider in 2.x to resolve the effective servlet path of the application. We've also recently updated it to support the case of an application with multiple DispatcherServlet instances (#13603).

We're not using that information consistently: StaticResourceRequest and Error pages registration rely on on the path in properties and their usage is unknown if there are several dispatcher servlets.

I don't really know if we need to bring back a concept of "main" DispatcherServlet but it feels to me that it would be useful that one is flagged as the one where auto-configuration can apply. We could have a default getAdditionalServletPaths that returns an empty set and that users could implement for their use cases.

The lifecycle of DispatcherServletPathProvider is also a bit weird (see this getBean call).

[philwebb]

The multiple dispatcher servlet paths seemed very sensible on the surface but unfortunately we have the assumption of a single primary dispatcher servlet pretty baked into the codebase. The reason we didn't really notice it in the past is because most of the calls that needed the path would use ServerProperties directly.

The clearest way forward for now appears to be to harden those rules and make it explicit that we expect one (and only one) primary dispatcher servlet. It's perfectly fine to have additional dispatcher servlets if needed, but they should not detect handler mappings or handler adapters and they must be manually configured.