Aggregate semantics in Policy Compiler

[TristonianJones]

Add aggregate semantics into Policy Compiler.

The CEL policy compiler initially started as first-match policy compilation, ensuring at
most one result would be produced from a policy expression evaluation. With aggregate
semantics, multiple outputs can be produced on a single pass. For those familiar with K8s
validating admission policies, the effect is similar.

Ported from cel-expr/cel-java/pull/1052

====

Aggregate walks through all matching rules (including nested ones) and appends them into a list:

rule:
  aggregate:
    - condition: "true"
      output: "'FOO'"
    - condition: "true"
      output: "'BAR'"

# Output: ['FOO', 'BAR']

Few noteworthy design decisions below. All examples assume all conditions matched:

1. For usability reasons, subrules under an aggregate ancestor will always have their lists flattened:

name: aggregate_flat_flattening_example
rule:
  aggregate:
    - rule:
        match:
          - condition: "resource.is_admin == true"
            output: "['GDPR_STANDARD', 'EU_B2C_NOTICE']"
    - condition: "true"
      output: "'FALLBACK'"
# Output: ['GDPR_STANDARD', 'EU_B2C_NOTICE', 'FALLBACK']

2. Base case of an aggregate rule is an empty list. Nested conditional rules within an aggregate rule which outputs optional.none() are pruned (except in cases where policy output explicitly emits an optional.none()):

name: optional_pruning_example
rule:
  aggregate:
    - rule:
        match:
          - condition: "1 == 2"
            output: "'EU_NOTICE'"
    - condition: "true"
      output "'ALWAYS'"

# Output: ['ALWAYS']

name: explicit_optional_none_example
rule:
  aggregate:
    - rule:
        match:
          - condition: "resource.is_b2c == true"
            output: "optional.none()"   # Explicitly authored by user

    - condition: "true"
      output: "optional.of('ALWAYS')"

# Output: [optional.none(), optional.of('ALWAYS')]

Note: nesting aggregate clauses is currently not allowed, and will result in a compilation error.

[TristonianJones]

@l46kok - This is a bit different from cel-java because output isn't initialized to a base step in order to avoid superfluous + [] appearing in the output expression. I believe you handle this with the constant folding and CSE in Java, but constant-folding isn't turned on by default for policy composition in order to preserve the round-trip to source metadata for coverage purposes.

[TristonianJones]

These moved into composer_test.go