CVO Integration during cluster upgrades

Goal: Prevent cluster admins from initiating OpenShift updates that could render installed Operators incapacitated.

Benefit hypothesis: Improve perceived safety to update to newer OpenShift versions.

Why is this important: Kubernetes is maturing and deprecating/removing APIs more often now. There are still lots of people out there using those and discovering the usage those to-be-removed APIs could go a long way to make users trust OpenShift as an enterprise platform. OLM can tell CVO about those APIs.

Acceptance criteria:

• a communication channel between CVO and OLM during updates to convey API usage
• either CVO or OLM doing impact analysis of an inbound OpenShift update
• a user-visible indicator when an update to a newer OpenShift would impact installed Operators