Hosted control planes (HyperShift) should consume recomended updates from OSUS

Problem Overview

Hosted control planes with HyperShift introduce a new architecture for OpenShift where the control plane and workers are decoupled and are represented but two distinct APIs, namely the `HostedCluster` API to represent cluster and control plane configuration and `NodePool` to expose lifecycle configuration. 

Today we set the channel-specific field to empty as the default CVO configuration does not apply to this new architecture. As a result, Cinncinati and the edged graph do not apply. The alternative provided today with HyperShift is guard railing versions within the HyperShift's operator code-base; while this works short-term, it can result in added complexity and even duplication long-term. 

Goals

This effort aims to evaluate the changes required for parity between the existing CVO + Cinncinati with the newly introduced HyperShift architecture.  Furthermore, one important outcome of this work is a clearly articulated spec of proposed changes to achieve partiy or suggestion of alternative methods. 

Notes

A possible implementation of this would result in adding a channel field to the spec of the HostedCluster resource and reporting availableUpdates in its status.
We should also decide whether the same should be done for NodePools (channel + status)
OR whether we should adopt a simpler pattern:

• NodePools can only be created by pointing to the same release image as the HostedCluster
• When updating a NodePool we can only update to the same release image as the HostedCluster. (for this last one we need to validate whether it's ok for nodepools to skip a minor release in the case of inplace upgrades)