[epic] Support upgrades of OLMv1 itself

[joelanford]

In order to make OLMv1 more than just a toy project upstream, we need to put effort into making it actually upgradeable in upstream Kubernetes clusters.

At a minimum, this would entail:

1. Documentation that lists valid upgrade paths
2. Testing, that provides confidence for making changes that will not break upgrades (and perhaps that could even report valid upgrade edges automatically)
3. A release process that makes new releases available in a consumable and consistent way.

If I'm dreaming big, I think this could look like:

• We design and deliver the following as prerequisites:
  • [epic] Implement upgrade tests for Catalogd catalogd#271
  • [epic] Implement upgrade tests for OperatorController #856
  • [epic] Operator Controller supports safe CRD upgrades #657
  • [epic] Support direct bundle installation #597
  • [epic] Extension health #390
  • [epic] Add support for handling helm charts #962
• We start shipping OLMv1 with a supported OLMv1 bundle format
• We start shipping an FBC catalog for OLMv1, containing edges verified by our upgrade tests
• We implement an installer that can bootstrap an OLMv1 release into a ClusterExtension
• We update our upgrade tests to use the bootstrapping mechanism so that we can reuse all of the existing pre-flight checks and health checking built into OLMv1.