Hardcode specific cluster constraints

In OCP 4.10 we have put an explicit API for cluster properties out of scope. As a result, upstream OLM will have no way of disambiguating specific cluster properties. However, in OCP we want to be able to sideload a few specific properties as a way to make the arbitrary constraints system valuable to users of OCP in 4.10.

UPDATE:

On the run up to feature freeze, Nick Hale and I agreed on a strategy:

1. On the upstream, we've introduced a system constraints provider, which could attach additional constraints to different cache entries
2. On the downstream, we wanted to introduce a system constraints provider that could query the cluster for the OCP version and apply the `MaxOpenShiftVersion` constraints. This PR on my fork contains all up and downstream changes. 

There's another valid alternative here, we ought to explore now that we have more time:

      1. On the downstream, surface some cluster properties somehow. Perhaps, as part of operator initialization, probe the cluster for the values (OCP version, node types, number of nodes, etc.)
      2. On the upstream, update the generic constraints implementation to be able to evaluate expressions containing the cluster properties. Bundle authors could then use CEL expressions to gate installations of the operator against the cluster version (and perhaps other attributes as well)

AC:

• Current design reviewed and ensured it aligns with the long term goal for system/runtime constraints
• Agree on nomenclature (system vs runtime constraints)
• Downstream OLM can surface OCP version property
• It is easy to surface new properties (even if hardcoded)

Note:

This set of properties is not defined yet aside from setting an OpenShift version property. We need to see if there are any other values that could be hardcoded.