extproc: reject invalid header names and values in header mutations (#9286)

ApplyAdditions and ApplyRemovals screen a mutation on the key being
non-empty, lowercase, not a pseudo-header, not `host`, and under 16384
bytes, but never on the key being a valid gRPC header name or the value
being a valid gRPC header value. gRPC validates application-supplied
outgoing metadata in `newStream`, which runs before the config selector
installs the filter chain, so nothing revalidates what this filter adds
afterwards, and `createHeaderFields` and the hpack encoder both take the
pair as given. An ext_proc server can set `x-user:
alice\r\nauthorization: Bearer <token>` and have the CRLF land verbatim
in the outgoing HEADERS block, or use a key such as
`x-user\r\nauthorization`, neither of which the application itself is
permitted to send.

Route both mutation paths through the validators already in
`internal/metadata` and drop the reserved `grpc-` key space, matching
the `HeaderValue` read rules in A102.

Per review, a mutation that fails validation now fails the RPC rather
than being silently skipped, and that applies to the screening that was
already there too (pseudo-header, `host`, non-lowercase, oversized key
or value). The shared key checks moved into a `validateHeaderKey` helper
so both paths report the same thing. The allow and disallow expressions
are unchanged and still keyed off `DisallowIsError`, since that is a
config decision rather than a validation failure.

RELEASE NOTES:
* xds: fail the RPC when an ext_proc server returns a header mutation
whose header name or value is not valid for gRPC