Optional aggregated ClusterRoles for viewing Gateway API and Envoy Gateway resources

Description:

Right now the gateway helm chart only creates one ClusterRole for the envoy gateway controller itself, and binds it only to the controller service account. There is no way for a cluster operator to grant a normal human user or a group read only access to Gateway API objects (gateways, httproutes, grpcroutes, referencegrants, tcproutes, tlsroutes, udproutes, gatewayclasses, backendtlspolicies) or Envoy Gateway objects (clienttrafficpolicies, backendtrafficpolicies, securitypolicies, envoypatchpolicies, envoyproxies, envoyextensionpolicies, backends, httproutefilters) without writing custom RBAC YAML by hand and maintaining it outside the chart.

Kubernetes already supports this well through aggregated ClusterRoles. The built in admin, edit and view ClusterRoles automatically pick up any other ClusterRole carrying a label such as `rbac.authorization.k8s.io/aggregate-to-admin`, `aggregate-to-edit` or `aggregate-to-view` set to true. If the chart shipped an optional set of ClusterRoles labeled this way (for example behind a flag such as `rbac.aggregatedClusterRoles.enabled`), any downstream consumer that already binds groups or users to the built in view/edit/admin roles would automatically gain proper read (or edit) access to Gateway API and Envoy Gateway resources, with no extra manual RBAC to maintain.

Proposed shape, roughly one new template such as `templates/aggregated-rbac.yaml`, gated by a values flag, for example:

```yaml
rbac:
aggregatedClusterRoles:
enabled: false
```

When enabled it would render something like:

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: envoy-gateway-aggregate-view
labels:
rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["gateway.networking.k8s.io"]
resources:
- gateways
- gatewayclasses
- httproutes
- grpcroutes
- tcproutes
- tlsroutes
- udproutes
- referencegrants
- backendtlspolicies
verbs: ["get", "list", "watch"]
- apiGroups: ["gateway.envoyproxy.io"]
resources:
- backendtrafficpolicies
- clienttrafficpolicies
- securitypolicies
- envoypatchpolicies
- envoyproxies
- envoyextensionpolicies
- backends
- httproutefilters
verbs: ["get", "list", "watch"]
```

An equivalent edit (and optionally admin) role could be added later with write verbs, following the same pattern.

This came up while managing cluster wide viewer groups in a downstream Kubernetes platform. Those viewer groups are bound to the built in view ClusterRole through the same aggregation mechanism, but users in that group cannot see Gateway API or Envoy Gateway objects today, since this chart does not expose any role they can aggregate into. Right now the only workaround is writing and maintaining custom ClusterRole and ClusterRoleBinding YAML by hand outside the chart, which drifts every time a new CRD or resource is added.

We are happy to open a pull request for this ourselves if the maintainers agree the approach above is reasonable and would be accepted.

Start with the gateway Helm chart templates and values, using the proposed templates/aggregated-rbac.yaml and rbac.aggregatedClusterRoles.enabled flag as entry points. Render the chart with the flag both disabled and enabled, then verify the aggregated ClusterRole labels, Gateway API and Envoy Gateway resources, and read-only verbs match the issue.

Written by the indexing model from the issue text.