Generalize EgressPolicy header modification with literal and secret-backed values

The current `inject_static_headers` API requires a credential reference for every header. Replace this credential-specific model with a generic request header modifier supporting `set`, `add`, and `remove`, with secrets as one possible value source.

```yaml
effects:
requestHeaderModifier:
set:
- name: X-Client-Version
value: "2026-09"
- name: Authorization
secret:
uri: substrate-secret://example.com/provider/api-token
prefix: "Bearer "
add:
- name: X-Client-Tag
value: substrate
remove:
- X-Internal-Debug
```

Proposed types:

```proto
message RequestHeaderModifier {
repeated HeaderValue set = 1;
repeated HeaderValue add = 2;
repeated string remove = 3;
}

message HeaderValue {
string name = 1;

oneof source {
string value = 2;
SecretHeaderValue secret = 3;
}
}

message SecretHeaderValue {
string uri = 1;
string prefix = 2;
}
```

Expose `RequestHeaderModifier` through `EgressRuleEffects.request_header_modifier`. This follows Gateway API’s `RequestHeaderModifier` operation model while extending header values to support secret references.

**Behavior**

- `set` replaces all existing values for the named header.
- `add` appends a value while preserving existing values.
- `remove` deletes all values for the named header; an absent header is a no-op.
- Header names are case-insensitive. Each header may appear only once across the operations, making operation order irrelevant.
- Values are either literals or secret references. Secret-backed values are constructed as `prefix + resolved secret`, preserving support for `Bearer ` without a template language.
- The modifier applies only to requests authorized by the first matching hostname rule.

Related: #1317 — Add extension points to egress policy.