Introduce a cluster scoped Config CRD

[kaczyns]

The Config CRD (name is open for debate, we're going with Tekton as an example) serves only to indicate where the Kabanero control namespace should be. It should have only one configurable field, which is the controlNamespace. If unspecified, it should default to kabanero.

The Kabanero operator should have a new controller for this CRD. The controller can run in the same container that the kabanero controller runs in (at least for the time being). It should only operator on an instance named cluster. For any other name it should update the status to indicate that it is being ignored (I believe this is what Tekton does). This also may be what Serverless does (with the KnativeServing object, but I'm less sure about this).

The Config controller should also install the following components, into the control namespace:

• admission controller webhook
• kabanero product dashboard (if available... this is a new cluster-scoped dashboard in addition to the namespace-scoped dashboard that already exists)
• Handle the creation of the OpenShift Console CRDs, like ConsoleLink (I think this is presently done in landing.go but it's really a cluster-level operation)

The corresponding configurating of the admission controller webhook should be removed from the kabanero controller.

The status of the Config CRD should indicate:

• The version of the kabanero operator (hopefully we can detect this!)
• Control namespace (what is it, and error if it did not exist)
• status of the admission controller webhook (can copy what was in the Kab CR status)
• overall status and message

There is some doc about CRD scope here:
https://sdk.operatorframework.io/docs/operator-scope/#crd-scope
note especially the tag/annotation/marker/whatever that you have to put in the golang struct to tell kubebuilder to generate the CRD with the correct scope.