Title: support mixing allow/deny policies with precedence

Description:
The current RBAC filter API has the following limitations:

• It binds a single action to a set of policies, in other words, we cannot mix the allow/deny policies in the same config
• It doesn't support policy precedence as all policies are specified in a map

Feature Request:

• Support action per-policy in the filter config
• Support policy with precedence

Use Cases:

• Some system (e.g. Istio) may have complicated layered access control design that uses both deny and allow policy at the same time with different priority.

Strawman design:

• Option 1: Incrementally change the current RBAC filter API

  • add the Action to the Policy message
  • add a new repeated Policy list_policies in the RBAC message and mark the current policies as deprecated

• Option 2: Introduce a new top-level config to simplify the RBAC filter API:

message Authorization {
  // The filter config is just a list of rules,
  // the first matched rule decide the action: ALLOW or DENY
  repeated Rule rules = 2;
}

message Rule {
  // Optional. A human readable string explaining the purpose of this rule.
  string description = 1;

  // A single match decide when to trigger the action
  Match match = 2;

  // action could be either ALLOW or DENY
  Action action = 3; 
}

message Match {
  // Optional. A human readable string explaining the purpose of this match.
  string description = 1;

  oneof type {
    MatchSet and = 2;
    MatchSet or = 3;
    Match not = 4;

    bool always = 5;
    HeaderMatcher header = 6;
    CidrRange source_ip = 7;
    CidrRange destination_ip = 8;
    uint32 destination_port = 9;
    StringMatcher requested_server_name = 10;
    Authenticated authenticated = 11;
    MetadataMatcher metadata = 12;
    string cel = 13;
  }
}

message MatchSet {
  repeated Match matches = 1;
}

Summary

• Option 1 tries to do everything incrementally, the change is less but I'm worried it's going to make the RBAC filter API more complicated in the long turn. Option 1 is fully backward-compatible and requires minimal changes in user code if they want to use the new features.
• Option 2 tries to do some some optimizations (most notably it has a much simpler and cleaner match/action pair), in the long term, we could rename the RBAC filter to just authz filter. Option 2 requires slight more but still reasonable changes in user code if they want to use the new feature, Envoy could also auto-translate the config if needed.

@mattklein123 @htuch @lizan would you mind to take a look and let me know what do you think about this? Thank you.