Further route caching improvements

Problem/Motivation

#3123401: Stop caching route lookups with query parameters or without results is optimizing route caching to no longer cache empty results and also by default not attempt to cache or lookup from cache any requests with query strings.

There are still some issue and room for improvement:

1. Most query strings do not affect routing, it's really more about the also-cached inbound path processing that can affect things than the route lookup.
2. Cache invalidation can be very frequent and possibly invalidate thousands of cache entries every time, due to the fact that any alias change invalidates the route_match

Steps to reproduce

Proposed resolution

Some ideas from the previous issue and discussions:

1a) It's fairly certain that a number of known query parameters do not influence the output of path processing, like destination, page, the login check thing and so on. But how do we know this in an efficient way for certain?
1b) I still think that removing caching completely is a viable option, especially for sites with frequent invalidations and not having a solution for 2. It's essentially caching for two fast queries, so on DB backend, it's one query instead of 2. See comment #23/#25 in that issue.

2) One rough idea is splitting up the route match cache tag, for example by the first part of the path, so instead of only route_match, we'd have route_match:blog, route_match:$site-section. And an alias create/update/delete, can then invalidate the cache much more specifically. Would need investigation what the impact is on additionally routing cache contexts and behaviors, such as domain/group-style prefixes, and also needs to handle language prefixes, would need to run on the alias without prefixes. Possibly inbound processing to collect cacheability metadata. But how much complexity is it worth to keep the cache, going back to 1b)

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet