k8s-operator/apis/v1alpha1: update DNSConfig CRD description

[irbekrm]

Update the DNSConfig CRD fields to better document how to use the CRD.

irbe@tailscale$ k explain dnsconfig
GROUP:      tailscale.com
KIND:       DNSConfig
VERSION:    v1alpha1

DESCRIPTION:
    DNSConfig can be deployed to cluster to make a subset of Tailscale MagicDNS
    names resolvable by cluster workloads. Use this if: A) you need to refer to
    tailnet services, exposed to cluster via Tailscale Kubernetes operator
    egress proxies by the MagicDNS names of those tailnet services (usually
    because the services run over HTTPS) B) you have exposed a cluster workload
    to the tailnet using Tailscale Ingress and you also want to refer to the
    workload from within the cluster over the Ingress's MagicDNS name (usually
    because you have some callback component that needs to use the same URL as
    that used by a non-cluster client on tailnet). When a DNSConfig is applied
    to a cluster, Tailscale Kubernetes operator will deploy a nameserver for
    ts.net DNS names and automatically populate it with records for any
    Tailscale egress or Ingress proxies deployed to that cluster. Currently you
    must manually update your cluster DNS configuration to add the IP address of
    the deployed nameserver as a ts.net stub nameserver. Instructions for how to
    do it:
    https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#configuration-of-stub-domain-and-upstream-nameserver-using-coredns
    (for CoreDNS),
    https://cloud.google.com/kubernetes-engine/docs/how-to/kube-dns (for
    kube-dns). Tailscale Kubernetes operator will write the address of a Service
    fronting the nameserver to dsnconfig.status.nameserver.ip. DNSConfig is a
    singleton - you must not create more than one. NB: if you want cluster
    workloads to be able to refer to Tailscale Ingress using its MagicDNS name,
    you must also annotate the Ingress resource with
    tailscale.com/experimental-forward-cluster-traffic-via-ingress annotation to
    ensure that the proxy created for the Ingress listens on its Pod IP address.
    NB: IPv6 only clusters are currently not supported.
    
FIELDS:
  apiVersion    <string>
    APIVersion defines the versioned schema of this representation of an object.
    Servers should convert recognized schemas to the latest internal value, and
    may reject unrecognized values. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

  kind  <string>
    Kind is a string value representing the REST resource this object
    represents. Servers may infer this from the endpoint the client submits
    requests to. Cannot be updated. In CamelCase. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  metadata      <ObjectMeta>
    Standard object's metadata. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  spec  <Object> -required-
    Spec describes the desired DNS configuration. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

  status        <Object>
    Status describes the status of the DNSConfig. This is set and managed by the
    Tailscale operator.

Updates #11019

[irbekrm]

Converting to draft- this PR adds a description that claims that we default nameserver image and tag if not provided via DNSConfig - actually we are not doing that yet.

[irbekrm]

Converting to draft- this PR adds a description that claims that we default nameserver image and tag if not provided via DNSConfig - actually we are not doing that yet.

Marking this as ready for review as the operator now knows how to default the nameserver repo and tag (implemented in #11991)