Allow installation of Prometheus operators without touching built-in CRDs

1.Proposed title of this feature request

• Allow installation of Prometheus operators without touching built-in CRDs

2. What is the nature and description of the request?

• Request is to allow for other Prometheus operators to be installed on the cluster with the condition that the built-in CRDs are not touched, so that a custom Prometheus stack can be deployed.
• Ability to scrape built-in exporters like node-exporters/kubelet/openshift-api/openshift-state-metrics/etc in order to gather necessary metrics to create the alerts they need.

3. Why does the customer need this? (List the business requirements here)

• Customer needs to access cluster system metrics to have visibility of cluster health and trigger alerts when needed.  Customer needs a custom Prometheus instance on each cluster for the following reasons:

• • The `openshift-monitoring` namespace does not allow for custom prometheus/alerts
  • The `openshift-monitoring` namespace cannot be altered as it is SRE managed
• To get access to the metrics and set up necessary alerts, they need a Prometheus instance deployed as a CR by a Prometheus operator in a different namespace other than `openshift-monitoring` so that the two operators do not conflict in any way.
• An existing RFE (RFE-4617) allows Remote-Write configuration setup in the built-in Promethus stack inside the `openshift-monitoring`namespace, but doesn't appear to meet the customer requirements as remote-writing in the SVC of an HA Prometheus cluster would result in metrics splitting between the two Promethus instances.  It would act as a LB.

4. List any affected packages or components.

• Prometheus