[INSTALL] Allow customization/patching of envoy-gateway-config with kustomize.

*Description*:

Currently, when using the install.yaml manifests as a kustomize base, you get this envoy-gateway-config:

```yaml
$ kustomize build | kubectl slice --include-name 'envoy-gateway-config' --stdout
# File: configmap-envoy-gateway-config.yaml (1053 bytes)
apiVersion: v1
data:
envoy-gateway.yaml: |
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyGateway
extensionApis: {}
gateway:
controllerName: gateway.envoyproxy.io/gatewayclass-controller
logging:
level:
default: info
provider:
kubernetes:
rateLimitDeployment:
container:
image: docker.io/envoyproxy/ratelimit:8fe6ea42
patch:
type: StrategicMerge
value:
spec:
template:
spec:
containers:
- imagePullPolicy: IfNotPresent
name: envoy-ratelimit
shutdownManager:
image: envoyproxy/gateway:v1.9.1
type: Kubernetes
kind: ConfigMap
metadata:
labels:
app.kubernetes.io/instance: eg
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: gateway-helm
app.kubernetes.io/version: latest
helm.sh/chart: gateway-helm-v0.0.0-latest
name: envoy-gateway-config
namespace: api-gateway
```

Unfortunately, you can't patch this easily because Kustomize can't patch inner yaml in a resource like this.
So you can't, for instance use :
```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyGateway
logging:
level:
default: info
encoder: JSON
```
To switch to JSON logging.

I don't have a strong opinion on how to achieve that, but a solution could be to add to the release machinery a way to bake into the binary the releases default (and either remove the defaults manifests, or just use the same value).
Using -ldfalgs -X or go build flags ?

Would the maintainers be willing to merge such a a feature ?

Start with the install.yaml manifests and the release machinery that produces envoy-gateway-config, then reproduce the documented Kustomize build and inspect the embedded envoy-gateway.yaml. Define a supported way to customize the nested EnvoyGateway configuration while retaining release defaults; done means the example logging change can be applied through the install manifests.

Written by the indexing model from the issue text.