Story: As a Quay administrator I want the Operator to watch updates to a specified config bundle secret so that I can manage Quay deployments with simpler GitOps workflows:

Background: An increasing number of customers want to manage all platform infrastructure components with GitOps only. Quay Operator currently supports that but makes for a complicated GitOps workflow since the config bundle secrets must be completed rip'n'replaced to trigger validation and rollout via the config editor / Operator.

Acceptance criteria:

• The Quay config is a ConfigMap instead of a Secret
• the Quay Operator watches all updates to the existing ConfigMap, triggering validation and rolling update of the quay deployment
• specifically the operators allows to leverage certs provided by cert-manager
• specifically the operator exposes the CA so it can be referenced from a Route and leverage the service CA operator to get the CA
• The Operator supports references to credentials stored in Secrets for any sensible data in the ConfigMap-based config bundle, so that for instance CloudCredential Operator can be used to request provider credentials in a GitOps workflow
• a apply / merge of updates to the existing config bundle is enough to update the Quay configuration
• configbundle updates are reflected in the status block of the CR
• this reconciliation allows for simple GitOps workflows pushing commit changes down to the cluster