Sublinear Route Filtering for Legacy Route Matching API

*Title*: *Sublinear Route Filtering for Legacy Route Matching API*

*Description*:
Since using the "legacy" route matching api in the [virtual host](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#config-route-v3-virtualhost)'s `routes` field still tends to be prevalent over using the newer xDS matching API with in-built support for sublinear matching, I wonder if 1) in https://github.com/envoyproxy/envoy/issues/6602

> Envoy could optimize based on presented configuration, for example a trie could be recovered from repeated patterns or a specific match order. This is challenging if the existing linear semantics are to be preserved and involves Envoy complexity.

Is worth further discussion and brainstorming.

I propose a new typed extension point within the virtual host that allows for preserving existing linear matching semantics (e.g. the matched route after optimization must be equal to what would be matched should a linear scan occur) but based on use-case allows for filtering out a large number of routes before matching (will post a draft PR later with an example API/implementation since the code may make this more clear). This new typed extension point will allow users to do the experimentation of applying which optimizations make sense for their use case.

How I envision this to work:
* A list of extension implementations (I'll refer to them as "optimizers") will take in an array of routes and return the list of indices corresponding to which routes they can potentially optimize.
* For each HTTP request, the request goes through each optimizer. Each optimizer returns a list of indices that matches for that request.
* Given all the indices returned by each optimizer, Envoy can then skip all routes for which an optimizer marked as it was responsible for but didn't return the corresponding index for the given request.
* In the case where two optimizers mark the same index as optimizable, both optimizers must return that index in order for matching to occur.

Example:
For routes:
* /foo
* /{some-regex-expression}
* /bar
* /baz

A path prefix optimizer (using a prefix trie under the hood) registers itself as responsible for indices `[0, 2, 3]`. When a new request is encountered with path `/baz`, the optimizer will return `[3]`. Given this information, Envoy can skip matching `/foo` and `/bar` and only attempt matching indices 1 and 3. Will have to research more into how hyperscan regex matching works, but with a list of optimizers, one for prefixes and one for regexes, I can envision at least for my internal use case a vast majority of requests only needing to match a few routes post filtering.

*Relevant Links*:
* Related to https://github.com/envoyproxy/envoy/issues/6602
* https://github.com/envoyproxy/envoy/issues/20609 may work well enough which would be nice to evaluate without the complexity introduced by such optimization