Add status field in ClusterVersion to report the target architecture i.e. heterogeneous or homogeneous arch.

Design choices:

• Who consumes this information and for what purpose?  This informs some of the subsequent choices, such as how we select which value to use.

• What is the new property name, and where does it live in the spec hierarchy?  status.cpuArchitecture?  spec.desired.cpuArchitecture?  Other?

• What are the new property values?  Presumably the same ones we use for spec, OTA-658.

• How does the CVO figure out what value to use? OTA-671

• Is the relevant release the current desired target (which may or may not have rolled out yet), or the most recently completed target (assuming that the arch extracted from that release matches the arch of any subsequent targets)?  Or?

If we are looking at release-metadata, we can use our existing version download pods, where CRI-O does the heavy lifting of pulling the image and launching our robot in the extracted filesystem.  If we need to look at image-manifest metadata, how do we get that info into the CVO?  Going from pullspec to image metadata requires knowing about Proxy config (which the CVO already does), ImageContentSourcePolicy (CVO doesn't know about this), pull secrets (CVO doesn't know about these), and maybe more.