Support sharing Wasm VMs across EnvoyExtensionPolicies for identical filters

*Description*:

I would like Envoy Gateway to support configuring the Envoy Wasm `vm_id` for Wasm extensions defined in `EnvoyExtensionPolicy`, so identical Wasm filters configured across multiple policies can intentionally share the same Envoy Wasm VM.

### Problem

We use multiple `EnvoyExtensionPolicy` resources to control which services/routes receive a given Wasm filter. In some cases, those policies configure the exact same Wasm filter logic, for example an `auth-filter-a` Wasm extension attached at a per-service level.

Today, each `EnvoyExtensionPolicy` results in a distinct generated Wasm filter/VM identity. Even when the Wasm filter configuration is logically identical across policies, Envoy Gateway generates unique VM IDs, so Envoy starts separate Wasm VMs instead of reusing one.

That preserves isolation by default, which is a good default, but there is currently no way for users to opt in to sharing a VM for the same filter across policy resources.

### Use case

I want to configure the same Wasm filter across multiple `EnvoyExtensionPolicy` resources and have Envoy use the same Wasm VM when the filter is intentionally identical.

For example:

```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: service-a-auth
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: HTTPRoute
name: service-a
wasm:
- name: auth-filter-a
vmID: shared-auth-filter-a
code:
type: HTTP
http:
url: https://example.com/auth-filter-a.wasm
sha256:
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: service-b-auth
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: HTTPRoute
name: service-b
wasm:
- name: auth-filter-a
vmID: shared-auth-filter-a
code:
type: HTTP
http:
url: https://example.com/auth-filter-a.wasm
sha256:
```

In this example, both policies intentionally configure the same filter, `auth-filter-a`, with the same Wasm module. The desired behavior is for Envoy Gateway to pass `shared-auth-filter-a` through to Envoy's `VmConfig.vm_id`, allowing Envoy to reuse the same VM for both filters.

### Proposed behavior

Add an optional `vmID` field to the `Wasm` API type in `EnvoyExtensionPolicy`.

Suggested semantics:

- If `vmID` is omitted, preserve the current behavior: Envoy Gateway uses its generated per-policy/per-filter identity as the VM ID, keeping isolation by default.
- If `vmID` is set, Envoy Gateway passes that value through to xDS `extensions.wasm.v3.VmConfig.vm_id`.
- Filters with the same `vmID` and same Wasm code can then share a VM according to Envoy's existing Wasm behavior.
- The field should be optional and non-empty when present.
- The existing `name` field should continue to identify the Wasm plugin/filter for logging/debugging, while `vmID` controls VM reuse.

### Why this matters

For deployments that attach the same Wasm filter through multiple `EnvoyExtensionPolicy` resources, the current behavior can create duplicate Wasm VMs for identical filter logic. A user-controlled `vmID` would let operators intentionally reuse a VM where appropriate, while keeping Envoy Gateway's current isolated default for everyone else.

This is particularly useful when policies are managed per service or per route, but the underlying Wasm filter is the same.

### Compatibility

This should be backward compatible because `vmID` would be optional. Existing policies that omit `vmID` would continue to get the current generated VM ID behavior and remain isolated.

### Alternatives considered

- Reusing the existing `name` field as the VM ID: this seems undesirable because Envoy's Wasm plugin `name` and VM `vm_id` have different meanings.
- Deriving a stable VM ID automatically from the Wasm code/configuration: this could unexpectedly change isolation behavior for existing users.
- Keeping the current behavior only: users cannot opt in to Envoy's native VM sharing behavior across policies.

[optional *Relevant Links*:]

- Envoy Wasm `VmConfig.vm_id` docs: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/wasm/v3/wasm.proto
- Current Envoy Gateway Wasm documentation: https://gateway.envoyproxy.io/latest/tasks/extensibility/wasm/

Start with the EnvoyExtensionPolicy Wasm API type and the existing translation that builds xDS extensions.wasm.v3.VmConfig. Compare behavior when vmID is omitted or set, then verify the generated VmConfig.vm_id for both cases and consult the linked Wasm documentation for the expected API behavior.

Written by the indexing model from the issue text.