xds/rbac: apply header matcher checks to nested and/or/not rules (#9258)

parseConfig only walks the top-level Permissions and Principals of each
RBAC policy when it applies the A41 header-name rules, so a header
matcher nested inside an and_rules, or_rules, or not_rule is never
checked. A control plane can put a `:scheme` or `grpc-` prefixed matcher
inside a nested rule to slip past the validation A41 says must reject
it, and a nested `host` matcher never gets rewritten to `:authority`, so
it silently fails to match the header grpc-go actually carries (a deny
policy on a nested host matcher fails open).

Walk the full permission and principal trees so both the :scheme/grpc-
rejection and the host to :authority rewrite reach matchers at any
depth. Doing it in parseConfig keeps the check in the one place that
already owns A41 validation, and folds the two former top-level passes
into a single recursive walk shared by permissions and principals.

RELEASE NOTES:
- xds/rbac: Fix a bug where nested `Principal` or `Permission` rules
with `:scheme` or `grpc-` prefixed header matchers were not rejected,
which could cause DENY rules to fail open.
- xds/rbac: Fix a bug where the `host` header matcher was not being
replaced with `:authority` in nested `Principal` or `Permission` rules.