Introduce spec.Source type in the CatalogSource CRD

[anik120]

Catalog images are exclusively container images hosted in image registries today. There's growing evidence to suggest that allowing catalog content to be packaged and published in other ways (such as as OCI images, or in git repositories, or even added to the cluster as configmaps) could streamline the process of building and maintaining these clusters, improving quality of life for catalog authors.

Introducing a new field spec.Source in the CatalogSource CRD, and adding the value image that calls the unpacking job that exists today, will lay the ground work for introducing new spec.Source type in the near term.

[joelanford]

I have a WIP PR for this in #59. As mentioned there, it is a lot of copy/paste from rukpak, which is good and bad:

• Good: rukpak's unpacking seems fairly solid
• Bad: its duplicate code

Personally, I think the best approach would be to:

1. Make a PR using just the stuff from WIP: introduce source union type #59 that handles image sources
2. Make a few follow-up issues:
   • Look into extracting the source API and implementation to a common place
   • Look into actually depending on rukpak APIs and treat catalogs as a type of Bundle (e.g. using a different provisioner class)
   • Look into improvements in the source.Result API which contains what could end up being a very large in-memory fs.FS when we start thinking of catalogs as bundles (perhaps io.ReadCloser is a better interface to use at that layer?).