Workflow where knative-serving/eventing spawns new namespaces feels unusual

At present, charmed knative is designed[^1] such that:
* the knative-operator charm deploys the upstream knative operator. This operator manages all knative serving/eventing deployments for us
* knative-serving (/knative-eventing) charms deploy/manage an instance of a `KnativeServing` (/`KnativeEventing`) CR which is acted upon by the upstream knative operator

The way someone might use these then is by:
```
juju deploy knative-operators
juju deploy knative-serving --config namespace=some-namespace [...other config]
```
This would result in the knative-serving charm creating a `KnativeServing` CR that requests for knative serving to be deployed in the namespace `some-namespace`, and the upstream knative operator will create this namespace/deploy things.

This pattern feels odd compared to other juju things. Typically, we'd expect applications to work within their models. Would it make more sense to design the knative-serving (/knative-eventing) charms to always ask for an instance *within their own namespace*, and then deploy them to a separate model? The workflow would then be:

```
# from kubeflow model
juju deploy knative-operators

juju add-model some-namespace
juju switch some-namespace
juju deploy knative-serving [...other config] # Note that `--config namespace` is removed
```

where the result is a knative serving instance in the namespace `some-namespace`?

This feels more Juju, but might be less practical. We package knative in the [kubeflow bundle](https://github.com/canonical/bundle-kubeflow) - can a bundle have multiple models?

[^1]: [Charmed Knative design spec](https://docs.google.com/document/d/12HESYEmpINEh_8-fVPcCqjXQemNJ3_Tmv6cKIWRogRQ/edit#heading=h.u6ud5wfl53hh)

Start with the Charmed Knative design spec linked in the footnote and review how the current knative-serving/eventing charms use the namespace config and KnativeServing/KnativeEventing CRs. Determine whether the proposed separate-model workflow is supported by Juju bundles; done means a decided workflow and an agreed design or documentation scope.

Written by the indexing model from the issue text.