`BackendTrafficPolicy`: emit `Retry-After` header on rate-limit 429 responses

Description:

The global rate-limit filter in EG emits the IETF draft-03 triple (x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset) on both 200 and 429 responses, but does not emit Retry-After on the 429.

Retry-After on 429 is the convention defined by RFC 6585 section 4, with the field itself defined by RFC 9110 section 10.2.3 as HTTP-date / delay-seconds. Operators today have to bridge this gap themselves, typically with a Lua filter via EnvoyExtensionPolicy that copies x-ratelimit-reset into Retry-After on 429. The information is already in the filter; only the emission is missing.

Proposal: add a option to BackendTrafficPolicy.spec.rateLimit (and the local rate-limit equivalent) that opts the rule or policy into emitting Retry-After: <delay-seconds> on rate-limited 429 responses, sourced from the same reset value the filter already computes. Sketch:

spec:
  rateLimit:
    type: Global
    global:
      emitRetryAfter: true   # or per-rule, mirroring xRateLimitHeaders
      rules: [ ... ]

The value would be an integer matching the current x-ratelimit-reset semantics: most-restrictive matched rule's seconds-until-reset, clamped to ≥1. Emission is conditional on the 429, not on every response, to match RFC 6585 section 4 semantics.

This works for both the RLS-backed global filter and the local rate-limit filter; the underlying delay value is already computed in both paths.

Relevant Links:

• RFC 9110 section 10.2.3, Retry-After: https://www.rfc-editor.org/rfc/rfc9110#section-10.2.3
• RFC 6585 section 4, 429 with Retry-After: https://www.rfc-editor.org/rfc/rfc6585#section-4
• IETF draft-ietf-httpapi-ratelimit-headers (active WG draft, v11): https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/
• Closely related, closed without delivering Retry-After: envoyproxy/gateway#5693, closed after the scope was narrowed to enabling the existing x-ratelimit-* headers on the local rate-limit filter; the original Retry-After ask was not addressed.
• Adjacent CRD surface already shipped in v1.8: envoyproxy/gateway#8279 (xRateLimitHeaders per-rule enum), same place the new option would live.
• Upstream Envoy dormant issues for context: envoyproxy/envoy#12356 (original draft-03 implementation), envoyproxy/envoy#3555 (custom response headers from the rate-limit filter/service).
• Envoy XRateLimitHeadersRFCVersion enum (frozen at DRAFT_VERSION_03): https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/common/ratelimit/v3/ratelimit.proto