Feature Flag Routing

## In what area(s)?
/area API
/area networking

/kind spec
/kind proposal

## Describe the feature

One of the things we hear from customers is that routing between revisions based on percentage isn't really of interest to them once in production. In practice they tend to lean more towards a model where only a select group of users are expected to use the latest versions so that everyone else (who need more stability) are not impacted during the testing phase. We call that "Feature Flag Routing". Where the routers (e.g. istio) route requests to certain versions based on some metadata in the message (e.g. perhaps some http header) rather than the random % based stuff. We'd like for Knative to eventually support this as an option. It's not clear if this can be done solely under the covers or whether it might result in an API change. If an API change might be needed it might be best to at least design it out prior to v1.0 when the API is locked down.

Some of the uses for the "select group":
- testers to test stuff prior to opening it up to everyone
- customers who opt-in for some kind of beta program
- customers who pay extra for access to really old versions that you may not want available to everyone
- might even want to direct certain users to certain versions of the service based on other criteria such as their SLA. Might be for slight difference in runtime performance or even to give certain customers their own dedicated revisions to use to provide a bit of isolation (either for security concerns or fear of noisy neighbors).

Start by reviewing Knative Serving's existing revision percentage-routing behavior and the API implications described in this issue. Compare metadata-based routing through routers such as Istio with the current model, then define the API or design changes needed for feature-flag and user-group routing.

Written by the indexing model from the issue text.