Multi-tenancy support

## Problem

Currently, the Knative serving data-plane components *ingress gateway*, *activator*, and *autoscaler* are cluster-singletons and shared amongst all users of a cluster. One implication of this architectural choice is that _every KService can reach every other KService_ within the cluster network-wise, regardless of namespaces or any additional isolation setup via `NetworkPolicy` resources.

## Describe the feature

True multi-tenancy would require complete separation of all platform resources, which is not entirely possible on Kubernetes as specific resources like CRDs have a cluster-wide scope. However, some extensions are required to separate the network traffic for different _tenants_ (defined as isolated user-groups of a Kubernetes cluster). There are multiple levels of isolations of those shared components that differ in complexity and resource usage. This [presentation](https://docs.google.com/presentation/d/1wpCB3clmIYS129EXnKNVYaw4PmuLtWAGG3f52XPPG08/edit?usp=sharing) gives an overview of the possible implementations that we (@nak3, @rhuss) can imagine.

In summary, it's about these three isolation levels:

### Multi Ingress Gateway (NetworkPolicy) Support


### Multi Activator Support


### Multiple Knative Control Planes


-----

Let's discuss which level should be approached. I'd propose to go for Leve 1 as this requires the least amount of changes and the least amount of resource overhead. The question will be how to map a _tenant_ to K8s concepts, i.e., `namespace`. Having one tenant per namespace seems to be too fine-granular and not very flexible. Instead, an additional grouping concept like a new CRD `KnativeMemberRoll` containing a list of namespaces associated with a specific tenant or an implicit grouping via namespace labels is suggested.

No source files, tests, or entry points are named. Start by resolving whether Level 1 multi-ingress-gateway isolation is the scope and how tenants map to namespaces, labels, or a KnativeMemberRoll; done would separate network traffic between tenants while accounting for shared Kubernetes resources.

Written by the indexing model from the issue text.