Overview

roxie currently only supports deploying Central and SecuredCluster into separate namespaces.
There were originally two reasons for this:

1. It simplifies teardown (just force-delete a namespace) and simplifies detection of existing deployments (does the namespace exist?).
2. Keeping the namespaces separate mimics multi-cluster deployments like a customer would use them -- deploying into the same namespace is actually just a special case. Also, this way we can test certain flows (delegated scanning), which would not be possible otherwise.

But as requested from colleagues there is a strong desire to have roxie support single-namespace deployments for ergonomic reasons. This is what this PR implements:

A new flag --single-namespace for the deploy and teardown sub-commands, which changes deployment and teardown logic to use a single-namespace approach. When used, the namespace stackrox will be used for both deployments.

Making this configurable (if desired) is not in scope for this PR.

Teardowns

The biggest obstacle for implementing the single-namespace mode is that teardown mechanism. Instead of simply deleting the respective namespace, we now need to delete only those resources from a namespaces belonging to either the Central or the SecuredCluster deployment.

Why not simply deleting the respective CR (in case of operator deployments), you may ask? Multiple reasons:

1. roxie shall be snappier than that, to optimize for quick iterations for engineers. We don't need to be careful, we can just delete resources in a brute-force manner so speed up redeployments.
2. roxie can also be used for testing operators which are currently in development and might not function as expected. Hence, we shouldn't block redeployments with roxie in case the operator has problems uninstalling the resources.
3. Some resources (e.g. PVCs, secrets) might need manual cleanup afterwards anyway to recreate a clean state.

That being said, roxies new teardown strategy, which seems to work pretty well, works as follows:

1. Initiate (async) CR deletion, this is a technical requirement, because without this step we cannot delete the CR finalizers (the operator would just re-add the finalizers immediately). Deleting the finalizers allows us to proceed with the deletion of the CR without being blocked by the operator.
2. Construct a list of all resource kinds to be taken into account for deletion as the intersection of what the installed components consist of (+ spawned resource kinds, such as replicasets and pods) and what the cluster supports.
3. Brute-force-delete all these resources using a label selector.
4. Delete other resource left-overs (secrets, PVCs).
5. Synchronously delete the CR.

This also seems to be pretty fast!

Deployments

For the deployments we actually don't need to do many changes. The wiring between Central and SecuredCluster needed to be changed to be parametrizable by the namespace.