Add optional Gateway API support for SolrCloud external addressability

Today, the Solr Operator supports `solrAddressability.external.method=Ingress` and `ExternalDNS` to make SolrCloud instances externally addressable. When `method=Ingress` and `hideNodes=false`, the operator:

- Creates a common Service for the SolrCloud
- Creates a per-node Service for each pod (when needed)
- Generates an `Ingress` with:
- One host pointing to the common Service
- Additional hosts (one per node) pointing to the corresponding node Services
- Keeps the Ingress rules in sync as SolrCloud nodes are added/removed

With the [retirement](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/) of the community ingress-nginx controller and the CNCF push towards **Gateway API**, it would be helpful if the Solr Operator could optionally use Gateway API resources instead of an Ingress, while preserving the existing addressability setup.

---

**Proposal (high level)**

- Extend `SolrCloud.spec.solrAddressability.external.method` to support a new value, e.g. `Gateway`, alongside the existing `Ingress` / `ExternalDNS`.
- Add a new configuration block for Gateway settings, for example:

```yaml
spec:
solrAddressability:
external:
method: Gateway
domainName: .example.com
hideNodes: false
nodePortOverride: 443
gateway:
gatewayRef:
name: shared-gateway
namespace: infra
sectionName: https
```

- When method=Gateway:
- The operator continues to create the same common and per-node Services as it does for method=Ingress.
- Instead of an Ingress, the operator creates Gateway API HTTPRoute resources:
- One HTTPRoute for the “cluster” hostname (ex. <>-common) -> common Service
- If hideNodes=false, one HTTPRoute per node hostname -> corresponding node Service
- These HTTPRoute resources are kept in sync with the SolrCloud’s replica count and lifecycle, similar to how the Ingress is today.
- The operator assumes the referenced Gateway already exists and is managed by the platform/infra team. It only manages the child HTTPRoute objects.

Example generated resources (conceptual):

```yaml
# Cluster entrypoint route
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: solr-cloud-common
namespace: solr
spec:
parentRefs:
- name: shared-gateway
namespace: infra
sectionName: https
hostnames:
- solr-cloud.example.com
rules:
- backendRefs:
- name: solr-cloud-common
port: 80
```
```yaml
# Per-node route (when hideNodes=false)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: solr-cloud-node-0
namespace: solr
spec:
parentRefs:
- name: shared-gateway
namespace: infra
sectionName: https
hostnames:
- solr-cloud-node-0.example.com
rules:
- backendRefs:
- name: solr-cloud-node-0
port: 443

```

---

**Questions for maintainers**

- Does the above API shape for external.method=Gateway and gateway.gatewayRef align with how you’d like to model Gateway support?
- For hideNodes=false, would you prefer:
- (a) One HTTPRoute per node hostname, or
- (b) A single HTTPRoute with multiple hostnames and rules?
- Would you consider an initial implementation that targets HTTPRoute only (HTTPS on a shared Gateway), with TCPRoute / advanced features as follow-ups?

**Motivation**

I’m running SolrCloud in Kubernetes with the Solr Operator and currently rely on an nginx-based Ingress for external access. As the Kubernetes community moves toward the Gateway API model for ingress across platforms, having first-class Gateway API support in the Solr Operator would make that transition much smoother and more future-proof.

I am interested in contributing to a potential implementation. If the general direction of this proposal is acceptable, I would be happy to help with a draft pull request

The issue names no repository files, tests, or entry points. Start by reviewing the existing Ingress-based SolrCloud external addressability and the solrAddressability.external configuration, then determine how Gateway API HTTPRoutes should represent the common and per-node Services; done means a maintainable API design and synchronized routes, with maintainer agreement on the open questions.

Written by the indexing model from the issue text.