Make catalogd's CatalogMetadata APIs available for operator-controller

[joelanford]

While we wait for operator-framework/catalogd#139, I propose that we start using catalogd's CatalogMetadata API instead of its BundleMetadata and Package APIs.

The CatalogMetadata API contains (almost) all of the FBC that the eventual catalogd file server will, so it is a good step forward, and is something that folks implementing some of the existing RFCs can use right now. This will ease an eventual migration to the catalogd file server.

Catalogd main branch currently has CatalogMetadata APIs enabled. We just need to ask catalogd maintainers to cut a release and bump our dependency on it.

[m1kola]

Sounds good! I think this also solves this todo:

operator-controller/cmd/resolutioncli/entity_source.go

Lines 120 to 125 in fd7cfb5

	// TODO: Reduce code duplication: share a function with catalogdEntitySource (see getEntities)
	// We don't want to maintain two functions performing conversion into input.EntityList.
	// For this we need some common format. So we need a package which will be able
	// to convert from declfcg structs into CRD structs directly or via model.Model.
	// One option would be to make this piece of code from catalogd reusable and exportable:
	// https://github.com/operator-framework/catalogd/blob/9fe45a628de2e74d9cd73c3650fa2582aaac5213/pkg/controllers/core/catalog_controller.go#L200-L360

But instead of converting declcfg into CRDs as initially suggested in TODO we operate on declcfg everywhere.

[m1kola]

Sorry, I misunderstood it at first. This ticket only aims at making CatalogMetadata available to operator-controller which was already done in #339 / #336.

To solve the todo mentioned above I created #342.

I think we can close this issue.