Update validations for fields referencing the name of something to follow Kubernetes

[everettraven]

Where possible we should restrict validation of fields representing names of things to follow the stricter RFC 1035 naming conventions. Where we need less restrictive naming validation we should fall back to the RFC 1123 conventions. We should not deviate from the validations outlined in https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

The following fields have been identified as needing updates to adhere to the above mentioned criteria:

• ClusterExtension.Spec.PackageName should be updated to follow the RFC 1123 DNS Label pattern and validations. We fall back to RFC 1123 for this field due to packages existing in the current ecosystem that start with numeric characters (3scale-operator is one such example).
• ClusterExtension.Spec.Channel would be updated to follow the RFC 1123 DNS Label pattern and validations. We fall back to RFC 1123 for this field due to channels existing in the current ecosystem that start with numeric characters (1.1.x is one such example that exists in the OperatorHub community catalog today).
• ClusterExtension.Spec.InstallNamespace would be updated to follow the RFC 1123 DNS Label pattern and validations. This is the restriction on Namespace names by Kubernetes (ref).
• ClusterExtension.Spec.ServiceAccount.Name would be updated to follow the RFC 1123 DNS Subdomain pattern and validations. This is the same validation that Kubernetes uses for ServiceAccount names (ref).

The RFC 1123 DNS Label validations can be found here: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names

The RFC 1123 Subdomain validations can be found here: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names