Simplify external service egress traffic setup

As discussed in #74, the current way to model an external service that a service within the mesh can route to is by modeling the external service as a VirtualNode. For example, if you had two services named Service-A and Service-B, and Service-B was an external service (e.g. gitlab) hosted at the DNS name `gitlab.my-intranet.com`. If you wanted the VirtualNode representing Service-A to be able to egress traffic to Service-B, you would model your mesh configuration as:

Service-A:
```
{
"meshName": "foo",
"virtualNodeName": "service-a",
"spec": {
"listeners": [
{
"portMapping": {
"port": 8080,
"protocol": "http"
}
}
],
"serviceDiscovery": {
"dns": {
"serviceName": "service-a.foo-mesh.local"
}
},
"backends": [
"gitlab.my-intranet.com"
]
}
}
```

Service-B:
```
{
"meshName": "foo",
"virtualNodeName": "service-b",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "tcp"
},
"healthCheck": {
"protocol": "tcp",
"healthyThreshold": 2,
"unhealthyThreshold": 2,
"timeoutMillis": 2000,
"intervalMillis": 5000
}
}
],
"serviceDiscovery": {
"dns": {
"serviceName": "gitlab.my-intranet.com"
}
}
}
}
```

The VirtualNode model contains many specifications which would not normally apply to an external service not within the control of the mesh (such as backends), while others still do (such as health checks).

This issue is to track the investigation of a general simplification of modeling external entities within the mesh.