[epic] Initial `kubectl operator` plugin updates for operator-controller and catalogd

With the imminent 1.0.0 releases of operator-controller and catalogd, we should circle back to our kubectl-operator plugin, update it to work with operator-controller/catalogd APIs and make those interactions the default experience (deprecating the OLMv0 implementation).

One of the most important new features the kubectl plugin should include is a way to query the contents of the ClusterCatalog objects on a cluster. This is a tricky problem to solve because the networking and authentication stacks between an off-cluster client and the on-cluster catalogd service are often environment-specific. Potential options include:

• kubectl port-forward, but this requires users to have permission to get information about the catalogd pod (and possibly its service) in order to setup the port-forward connection.
• kubectl proxy, but no client authentication to the in-cluster service is supported. This would be a problem if we ever want to require client authentication in order to access catalogd from outside the cluster. Are there any advantages of proxy over port-forward that we should consider?
• An Ingress or Gateway - these APIs are the traditional way to expose cluster services outside the cluster, but there are many implementations, each with nuances, and OLM cannot really make assumptions that there will even be an ingress or gateway controller running on every cluster.
• Service with a NodePort - this configures each node to start a listener on the specified port for the specified protocol, and all nodes proxy connections to the in-cluster service. Downside is that it requires a port reservation, and clients would need a way to discover the node IPs and port assignment (not insurmountable, but something we'd have to consider carefully).

Because all of these options have pitfalls, we may need to design a flexible solution that enables distributions that include OLM to select which of these to support. And ideally the client could automatically discover which technique to use. Since clients will be required to query for ClusterCatalog to know what is even available to query, perhaps catalogd could include external URLs in the ClusterCatalog status?

In addition to the challenges with exposing catalog content off-cluster, we should also implement some or all of:

• ClusterExtension get/list/install/upgrade/uninstall
• ClusterCatalog get/list/add/remove, and maybe mechanisms to update availability, labels, priority, etc.

We should definitely plan to implement a really nice UX for discovering the current state of what is actually present on the cluster. We can implement custom printer columns, sorting, etc. that can really enhance a user's understanding of the state of the system.

There may be additional iterations on this effort (for e.g. as we discover possible benefits of new printer columns or something else), but for this initial iteration we plan a functional breakdown to give solid experiences in stages. This may enable other features (for e.g. service account permissions evaluations).

These phases are captured as sub-issues, and duplicated here for those expecting a table:

• #1767
• #1768
• #1769
• #1770
• #1771
• #1772
• #1765
• #1853
• #1766
• #1807
• #1850
• #1851
• #1852

Start by reading the linked phase sub-issues (#1767, #1768, #1769, #1770, #1771, #1772, #1765, #1853, #1766, #1807, #1850, #1851, and #1852) to identify an independently scoped contribution to the kubectl-operator plugin. Done means the selected phase implements its stated operator-controller or catalogd experience and provides the corresponding user-facing kubectl behavior.