matcher: new custom predicate

[wbpcode]

New custom predicate of matcher API.

In the previous API, the SinglePredicate could be used to composite various matching conditions. However, it's very flexible but isn't easy to use. Especially if there are some common matching compositions that will be used frequently, for example, the headers matching.

This PR introduced a new CustomPredicate to present an custom matching condition. This new predicate type will take the protocol-specific data as input, and a bool as output. All the input and match logics are defined by the extension config.

This new type could be used when there are some common matching compositions. We can define a custom predicate as a composition of multiple different but releated matching conditions.

In addition, any protocol-specific data matching or non-string data matching could use this new CustomPredicate.

Take the headers match as an example. If there are three headers need to match, then the config in previous API would be:

//                 - predicate:
//                     and_matcher:
//                       predicate:
//                       - single_predicate:
//                           input:
//                             name: header
//                             typed_config:
//                               "@type": type.googleapis.com/envoy.type.matcher.v3.HttpRequestHeaderMatchInput
//                               header_name: version
//                           value_match:
//                             exact: v1
//                       - single_predicate:
//                           input:
//                             name: header
//                             typed_config:
//                               "@type": type.googleapis.com/envoy.type.matcher.v3.HttpRequestHeaderMatchInput
//                               header_name: user
//                           value_match:
//                             exact: john
//                       - single_predicate:
//                           input:
//                             name: header
//                             typed_config:
//                               "@type": type.googleapis.com/envoy.type.matcher.v3.HttpRequestHeaderMatchInput
//                               header_name: id
//                           value_match:
//                             exact: "123"

And with the new API, the API could be:

//                 - predicate:
//                     custom_predicate:
//                       custom_match:
//                         name: multiple-headers
//                         typed_config:
//                           "@type": type.googleapis.com/envoy.type.matcher.v3.HttpHeadersCustomMatcher
//                           version:
//                             exact: v1
//                           user:
//                             exact: john
//                           id:
//                             exact: "123"

Based on the new API, the configuration will be more simple and easy to read or manage.

[markdroth]

As per discussion in envoyproxy/envoy#26861, I don't think this is what we want. The intent of the generic matcher API was to explicitly decouple inputs and matchers so that the two can be specified independently. I would prefer not to move away from that design principle.

[wbpcode]

cc @markdroth Thanks. And I will close this PR temporarily. See the discussion in the envoyproxy/envoy#26861 for more detail.