Improve the "installation" experience : kubectl apply -f URL

The "installation" of fabric-operator to a Kubernetes cluster involves little more than the registration of the operator CRD types to the Kube API controller.

Highlight this feature by installing the operator to a target namespace, using a single `kubectl` (or kustomization overlay) and a network URL. A great reference of this feature is action can be found at the Argo Workflows [Quick Start Guide](https://argoproj.github.io/argo-workflows/quick-start/), illustrating how a multi-component configuration can easily be applied to a cluster with a single copy/paste command block for common deployment targets.

Emulate Argo's 'manifest-based' installations, providing a "one click" activity to realize a Fabric base layer on a target Kubernetes. Effectively Argo is generating the output of `kustomization` builds, and storing the outputs of the kustomization in revision control. Not only is this technique an incredibly nice accelerator for new start projects, but it sets the basis for a revision-and-change management strategy for the operator as a "platform."

Note that this applies only to starting the operator, console, RBAC permissions to a target namespace only, and a parallel Nginx for ingress. No configuration of a Fabric network is required - just get everything in order for users to start constructing networks with ansible, kubectl/CRDs, or the Console GUI.

Common deployment targets / manifests include:

- EKS
- IKS
- localhost with KIND
- localhost with Rancher / k3s
- localhost with minikube

Start with the Argo Workflows Quick Start Guide linked in the issue, then inspect the operator's existing kustomization and manifest structure. Done means the operator, console, namespace-scoped RBAC, and parallel Nginx ingress can be installed for the listed Kubernetes targets through a single kubectl URL or kustomization overlay, without configuring a Fabric network.

Written by the indexing model from the issue text.