Feature Request: Support user-defined `:authority` header for `h2c` gRPC `ExtensionService` connections

[kahirokunn]

What this PR does / why we need it

This pull request adds first-class support for setting a user-defined :authority header when an ExtensionService communicates with its upstream over clear-text HTTP/2 (h2c).

Until now, Envoy’s gRPC client fell back to the internally generated cluster_name when the header was not explicitly configured. Because those names are not valid hostnames, upstream services that rely on virtual-host–based routing could not match the request. For TLS (h2) connections the problem could be worked around by setting spec.validation.subjectNames[0], but no equivalent existed for h2c.
See issue #6167 for background.

Design overview

CRD	Field	Type	Default	Description
ExtensionService	spec.authority	string	empty	Overrides the :authority header for h2c connections. Ignored for h2. Must be a valid DNS host label or FQDN.

• If spec.authority is non-empty and protocol: h2c, Contour injects the value into the generated CDS/LDS as :authority.
• If the field is omitted, the current fallback to cluster_name remains unchanged, preserving backwards compatibility.

Usage example

apiVersion: projectcontour.io/v1alpha1
kind: ExtensionService
metadata:
  name: authz-grpc
spec:
  protocol: h2c
  authority: authz.example.com   # NEW
  services:
  - name: authz
    port: 50051

Backwards compatibility

• No behavioural change for existing manifests; the new field is optional.
• In the unlikely event an operator relied on cluster_name being sent, they can leave spec.authority unset.