Multiple NEG/Backend support about gke-autoneg-controller

[rosmo]

I created support for multiple backends a bit over a year ago and we are now revisiting the issue. I suggest the following (and I'm very happy to hear any opinions on these):

1. Add a new annotation syntax matching the cloud.google.com/neg annotation:

cloud.google.com/neg: '{"exposed_ports": {"80":{},"443":{}}}'
controller.autoneg.dev/neg: '{ "backend_services": { "80": { "name": "foo", "max_rate_per_endpoint": 1000 } , "443": { "name": "bar", "max_connections_per_endpoint": 42 } } }'

2. We keep the existing annotation style for backwards compatibility for "version 1.0", but emit a deprecation warning.
3. We report status via both via new and old status annotations when there is a single port installed, only via new one when multiple ports are specified.
4. We remove the old-style annotation in "version 1.x".

[rwkarg]

I did basically the same thing as @rosmo mentioned in point 1 with the addition of an optional internal property (bool) to handle regional backend services on Internal Load Balancers (region pulled from http://metadata.google.internal/computeMetadata/v1/instance/attributes/cluster-location). That addressed #23, too

[rosmo]

@rwkarg would you be willing to do a PR?

[rwkarg]

I wrote our not-autoneg controller in C# so while it was a great learning experience into how Kubernetes controllers work, it's not conducive to a PR.

One thing to keep in mind is that Internal LBs currently have regional backend services. I don't know what the structure would be with potential globally routable Internal LBs (similar to how L4 Internal load balancer can be configured to be globally routable) would look like. A simple bool for internal may or may not be appropriate for some future state.

[soellman]

Fixed by #34