* windows: enhance vpc-bridge plugin to use HNS V2 APIs by default

Presently, in the `vpc-bridge` plugin, we use HNS V1 APIs to create the HNS network and the HNS endpoint. Once the endpoint is created, we use either V1 or V2 APIs for attaching the endpoint to the container.

Given that V2 is the way forward where Microsoft supports newer features, we are converting our plugins to be V2 first. In this commit, we make the following changes-
- We use HNS V2 to create the network
- We use HNS V2 to create the HNS endpoint

After that, we will use either V1 or V2 to attach the endpoint to our container/namespace depending upon the runtime.

* windows: add support for port mapping in vpc-bridge plugin

Presently, the vpc-bridge plugin silently ignores any port mapping between container to host for the configured endpoint.

As per the current CNI convention, plugins can request that the runtime insert this dynamic configuration by explicitly listing their capabilities in the network configuration. Dynamic information (i.e. data that a runtime fills out) should be placed in a runtimeConfig section. Reference: https://www.cni.dev/docs/conventions/#dynamic-plugin-specific-fields-capabilities--runtime-configuration

`portMappings` is one such capability. This change adds the support for creating NAT port mappings between container and host ports as configured by the runtime.

This is a bug fix in the `vpc-bridge` CNI plugin for Windows where we need to use `Search` parameter in `DNS` configuration for setting multiple domains used for short hostname lookups. Earlier we were using `Domain` which is a single string.

This change fixes this issue.

1. CNI plugin depends on vpc-cni-k8s-connector executed in EKS Windows nodes.
2. Call is made to vpc-cni-k8s-connector with podname, pod namespace and path to pipe as input args.
3. CNI receives output over named pipe and vpc-cni-k8s-connector logs over stdout.
4. CNI plugin creates a named pipe, start listener and read pipe connections to receive output from vpc-cni-k8s-connector