Kube test network : illustrate a deployment spanning multiple Kubernetes clusters

#644 brings up the need to demonstrate how Fabric networks can be defined across multiple namespaces within a single cluster.

The requirements in the "cross namespace" case include:
- Update configuration URLs from `Service` name to FQDN based on Kube DNS
- Update TLS CSR / SAN host names to include FQDN hostnames
- Configure Calico and/or networking policies

In addition to _cross namespace_ networks, there have been a number of requests to support and/or demonstrate the use of **_cross cluster networks_**. This topology is better aligned with a realistic Fabric consortiums spanning multiple organizations, each with privately managed infrastructure.

The kube test network includes a couple of mechanisms that enable this pattern. Employ these to illustrate the necessary mechanics for Fabric networks spanning multiple, ephemeral clusters:

- `kind create cluster --name X` : use KIND to bootstrap multiple clusters. (Introduce a kube context into the driver scripts.)
- Nginx ingress controller : bind multiple Nginx ingress controllers on the host NIC, using different ports.

Each sub-network should be associated with a DNS domain name, ideally using a DNS wildcard matching service (or `dnsmsaq`?) to associate the Service Ingress points to the correct Nginx service. For instance, assume the host OS has been assigned an IPv4 address of 1.2.3.4, we can set up two clusters, each with a unique Nginx port (8888, 9999). In this case, we will want to associate any traffic between the networks to route over the ingress:

*.org1.example.com --> 1.2.3.4:8888
*.org2.example.com --> 1.2.3.4:9999

Instead of using the FQDN with Kube DNS URLs, Fabric services should be configured to communicate _across_ kube networks by traversing the Nginx ingress to the respective cluster.