Moved `UpdateStatus` from `config.openshift.io` group to a new
`update.openshift.io`, because config did not feel like a good fit
(there’s no configuration involved) and none of the other existing
groups felt appropriate.

Initial draft used a non-namespaced API, because in standalone clusters
it would be a singleton scoped to the cluster, semantically. We expect
the concept to work with HCP too though. There the resource would need
to live in the management cluster apiserver and would be scoped to a
*hosted* cluster, not the management cluster (management cluster would
need one too, though). Therefore, we would need a namespaced,
functionally equivalent CRD for HCP, which seems like higher effort and
complexity than the minor awkwardness of using a namespaced resource in
standalone clusters.

Adding a resource reference to this level improves the cohesion with
workerPools part of the API, and can be useful in standalone/hcp
scenarios where controlplane is represented by different CRDs.

We are expecting use cases for more flexible metadata about the versions
involved in the update, such as 'architecture' for pseudo-updates when
clusters are migrated from `x86_64` to `multi`. The original two boolean
flags were replaced with a generic list of name+type+value triplets.

Generated with:

```
./tests/hack/gen-minimal-test.sh update/v1alpha1 v1alpha1
```

- Use `+kubebuilder:validation:Required` consistently (not `+required`)
- Do not mention (assume) underlying controller name
- Integers use `int32` types with enforced bounds
- Constants are `PascalNames` by convention
- GoDoc start by JSON name by convention
- Other GoDoc description tweaks

Make the `ResourceRef` type follow [OpenShift API conventions](https://github.com/openshift/enhancements/blob/master/dev-guide/api-conventions.md#use-resource-name-rather-than-kind-in-object-references).

I also considered to follow the ["Use Specific Types for Object Reference"](https://github.com/openshift/enhancements/blob/master/dev-guide/api-conventions.md#use-specific-types-for-object-references-and-omit-ref-suffix) more strictly and introduce speficic types instead using `ResourceRef` everywhere but consistency felt much worse (control plane would need ClusterVersion/HostedCluster reference, status insights would need just names, pool references would need MCP/NodePool but not in control plane...). Consistency is also a value, and because we use resource references at different places, it felt better to stay consistent everywhere.

CI enforces the presence of listType annotations on slices. List of resources is not a set, because resources are not scalars. It is not simple map because resource does not have a suitable key field. So it must be atomic I guess?

OpenShift API convention forbids bool usage and enforces this with CI. While I could argue for an exception (reasoning behind the convention does not apply in this case, as it would be easy to migrate from bools to strings if necessary), we can also simplify the API and make the metadata a simple key->value map, similar to `labels`. Value is optional and with empty value the presence of the key has a boolean=true semantics. It simplifies the API and possibly even improves the usability for clients.