Ext Proc Access Logs

*Description*:
Envoy supports [ext-proc access logs](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_proc_filter#access-log-fields) containing information related to ext-proc filter execution, such as latency, number of calls, volume of traffic, etc.

The information is available for each ext-proc filter independently in a namespace bearing the filter's name, see [here](https://www.envoyproxy.io/docs/envoy/latest/version_history/v1.27/v1.27.0#minor-behavior-changes): “ ext_proc: Filter metadata containing ext proc stats has been moved from ext-proc-logging-info to a namespace corresponding to the name of the ext_proc filter.”

Currently, EG generates filter names based on EnvoyExtensionPolicy metadata and ext-proc list index, e.g. `envoyextensionpolicy/default/policy-for-route-2/extproc/0`.

If users need to enable ext-proc logs, they have to rely on EG naming conventions in their `EnvoyProxy` access log formatters. Furthermore, when there are multiple ext-procs with possibly different required log formats, central management in `EnvoyProxy` becomes a real challenge.

Ideally, EG should make it possible for users to enable ext-proc access log fields without relying on internals and with some degrees of freedom. There are several aspects to consider:

**Access Log Target**
* Option 1 - enrich existing HTTP access log(s) already configured by users in EnvoyProxy. Each existing log will have an additional flag for allowing ext-proc fields to be added. When enabled, ext-proc logs would only be added to HTTP access logs that ext-proc logs are allowed for.
* Option 2 - create a dedicated log for all/each ext-proc.

**Access Log Content**
* Option 1 - Summary: users can't determine the specific fields added to log. EG will add the entire filter state `%FILTER_STATE(:PLAIN)%` to the json/string format.
* Option 2 - User-Defined fields:
* Users can list the required fields (`request_body_call_count`, `immediate_responses_sent`, ... ), EG will add them to the log, OR
* Users can add a proper JSON/String log format, which EG will merge with the envoy proxy format.

**Filter Instance Identification**
* Option 1 - Filter Name: EG will use the filter name as a json key prefix or some other string format
* Option 2 - User-defined name, possibly using substitution formatter, like cluster alt stat name.

**Granularity**
* Option 1 - `EnvoyProxy`: opt-in globally. The relevant config (access log fields, names, ... ) would be created for each ext-proc in the HCM's filter chain and added to the HCM access log.
* Option 2 - `EnvoyExtensionPolicy`/`EnvoyExtentsionPolicy.extproc[*]` : allow per EEP/Ext-Proc enablement (and possibly stat name and field configuration).