Add support for honoring upgrade edges defined in the catalog

[awgreene]

Background
OLM V0 had a concept of an upgrade graph, which defined linear upgrade graphs that users had to proceed through, learn more here: https://olm.operatorframework.io/docs/concepts/olm-architecture/operator-catalog/creating-an-update-graph/

Story

• As an OLM V1 user, I would like to respect upgrade edges defined by operator authors.

Demo Script:

1. Install OLM v1.
2. Create an Operator CR that uses the spec.Version field to install operator Foo at version n.
3. Wait for the operator Foo to install
4. Attempt to change the spec.Version to version m, which is not a supported upgrade edge
5. Check that the upgrade fails because it isn't a valid upgrade edge
6. Update the spec.Version field to n+1, which is a supported upgrade edge.
7. Check that the upgrade proceeds as expected.

Out of Scope

• If operator foo is installed at version n, we will not proceed if the user updates the spec.Version field to a value that could be reached after a series of upgrades. IE: Fail if operator foo is installed at version n and then the user updates the spec.Version field to n+2.
• There is no expectation of reporting available upgrade edges in the operator CR Status.

Things to consider:

• How can we map installed content to catalog content
• How can we respect bundle replaces fields
• How can we respect bundle skips fields
• How can Variable source that considers installed content

Proposed issues:

• Introduce variable source for installed bundles
• Collect "installed" bundles
  -- @perdasilva proposed an BundleDeployment CR annotation that links installed content to a catalog
  -- Feed "installed" bundles into resolver
• Introduce variable source for "upgrade edges"
  -- Introduce channel constraint
  -- Introduce replaces constraint
  -- Introduce skips constraint
• Is disabled by default, can be enabled using the Feature Gate functionality proposed in Introduce Support for Feature Gates #255

Follow Ups:

• Update the demo script to reference an actual operator and version.
• Create an issue to consider skipRange

[awgreene]

Considering that @m1kola is currently assigned to #206, I've reassigned this ticket to @jmprusi

[jmprusi]

I can't edit the body of the issue, please add as tasks:

#268
#267