Create entity source implementation with registry v1 client

[awgreene]

User Story:

As a Deppy User, I would like to use Deppy to consider if a set of constraints can be met by content within a catalogSource.

Background:

• The goal of the first milestone is to install/uninstall an operator.
• The operator that the milestone 1 installs will ultimately need to come from an existing catalogSource, as the alternatives would require implementing a new storage API for an operator, which was deemed too much work for milestone 1.
• The team has opted to wrap the existing registry client within a "Deppy Source Interface", constraining the Deppy library to only sourcing content from catalogSource but allowing us to reach the e2e milestone quickly.
• This approach will also allow us to write most of the code that will eventually be used by the "DeppySource catalogSource adapter" to convert existing content into the  format desired by Deppy.

Acceptance Criteria:

• Deppy can be provided with a catalogSource, treat it as an EntitySource, and retrieve the bundles and store them in a cache.
• Deppy can be notified that a catalogSource has been updated, retrieve the new content, and update the cache.
• Deppy can be notified that a catalogSource has been deleted and remove that source and it's entities from the cache.
• A test is implemented ensuring that Deppy can communicate with catalogSources.

Out of Scope:

• Using the registry client in the operator controller.

[awgreene]

This is being moved to Milestone 2b, for the purposes of Milestone 1 we are returning a hardcoded list

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.