[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 automatically 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 as a helm chart
• 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.