formatter: support sha256 request header substitution

## Description

Add built-in request-header substitution formatters that return a one-way SHA-256 digest instead of the original header value.

Proposed syntax:

```
%REQUEST_HEADER_SHA256(X?Y)%
%REQ_SHA256(X?Y)%
```

The operator would select request header X, optionally fall back to Y when X is missing or empty, and return a lowercase hexadecimal SHA-256 digest. If neither header has a nonempty value, the operator would produce no value.

This supports privacy-preserving request correlation and consistent hashing for internal gRPC services such as ext_authz. Today, gRPC initial metadata accepts built-in substitution formatters, but copying a sensitive request header into another metadata key can expose that value in router debug logs. Hashing before formatting avoids creating a plaintext copy while preserving deterministic affinity.

The implementation can reuse the existing request-header formatter parsing, Envoy crypto utility, and hex encoding. It would add formatter unit tests, substitution formatter documentation, and a release note. This is related to the broader sensitive-header logging concern in #9652 but does not claim to solve that issue generally.

Start with the existing request-header formatter parsing and the Envoy crypto utility, then review how hex encoding is used. Add formatter unit tests, substitution formatter documentation, and a release note; done means both proposed syntax forms hash the selected or fallback header and produce no value when neither is nonempty.

Written by the indexing model from the issue text.