We need the ability to specify networking details for each VSphereMachineConfig within a single EKS Anywhere cluster

**What would you like to be added**:
Currently EKS Anywhere vsphere provider assumes all nodes will exist in a single network, defined in spec.network of VSphereDatacenterConfig. It also assumes DHCP will be used.

We need the ability to specify networking details for each VSphereMachineConfig within a single EKS Anywhere cluster, such that we can disable DHCP, specify nameservers and gateways and set the vsphere network, etc.

We would like this to be achieved via an optional network field in the spec of VSphereMachineConfig.

This network struct should map to the resultant VSphereMachineTemplates' spec.template.spec.network.

**Why is this needed**:
We are currently a large VMWare Tanzu customer and are interested in using EKS Anywhere (we are also a large AWS customer). However, the lack of flexibility in network configuration means that we cannot use EKS Aywhere currently. Our clusters have multiple classes of nodes. One of these node classes is an Istio gateway node, which must be deployed in a separate "DMZ" vsphere network. Additionally, none of our networks use DHCP - we disable it on our VSphereMachineTemplates and use an Infoblox IPAM controller, running on the management cluster instead.

We can do this with upstream CAPI and Tanzu via a separate VSphereMachineTemplate directly, however, AWS have made a design decision with EKS Anywhere to implement custom EKS Anywhere CRDs, which do not expose the full flexibility of the underlying CAPI / CAPV APIs.

An example of the network spec within our VSphereMachineTemplates:

```
network:
devices:
- dhcp4: false
gateway4: #@ "{}".format(data.values.DEFAULT_GATEWAY_DMZ)
nameservers:
- #@ "{}".format(data.values.DNS_RESOLVER_1)
- #@ "{}".format(data.values.DNS_RESOLVER_2)
- #@ "{}".format(data.values.DNS_RESOLVER_3)
networkName: #@ "{}".format(data.values.VSPHERE_NETWORK_DMZ)
searchDomains:
- #@ "{}".format(data.values.INFOBLOX_DNS_ZONE)
```

Start at the VSphereMachineConfig spec and trace how it becomes the VSphereMachineTemplate spec.template.spec.network. Add the optional per-machine network configuration so values such as DHCP, gateways, nameservers, search domains, and networkName are preserved, then verify that different machine configs can produce their intended network settings within one cluster.

Written by the indexing model from the issue text.