Construct a Peer Ingress alias and Service for Gateway Client access

With Fabric 2.4, the Gateway Client feature allows an application developer to connect to a Gateway Peer, or proxy, to the ledger. Behind the scenes, the gateway peer will dispatch contract invocations and requests to a set of Peer gRPCs nodes, providing both reliable / stable network connections as well as some level of load balancing based on maintaining a balanced ledger height.

Implement, in the operator, logic and API extensions for the Peer CRD, such that the peer spec includes a delegation of `gatewayPeer: true`. When operator reconciles a peer spec with the "gateway peer" flag enabled, it should construct a k8s Service, Ingress, and certificate / SAN alias for the host such that it can be consumed by a gateway-client enabled application.

Some attention to (and overridden if possible), the k8s load balancing strategy for client -> gateway connections should be made. By default this is "round robin" across Deployments backing a Service.

Also note that the k8s Service should support TWO different URLs / SANs for access:
- external traffic routed via Ingress
- internal traffic routed via K8s internal / namespace-local networks.

Start with the Peer CRD and the operator's peer reconciliation entry point, then inspect how Services, Ingresses, and certificates or SAN aliases are represented. Trace the requested gatewayPeer flag and Kubernetes client-to-gateway load-balancing behavior. Done means the API accepts the flag and reconciliation provides external and namespace-local URLs with the required aliases.

Written by the indexing model from the issue text.