Headless Service mode

Nobody has claimed this yet.

We currently have "proxied" Service mode and "proxyless", which is really just "singleton Endpoint with failover" mode.

Some applications/frameworks can do client-side load balancing. For those we should support "headless" service mode. The idea here is still to run without a proxy, but lift the limit on having just a single Endpoint backing the service. Instead, the Endpoint number would be unlimited, and the Service would advertise them via Endpoints status property (containing address/port information). Clients could then watch the (headless) Service object and change their routing accordingly.

This is technically a breaking change to the model, so we can go about it at least two different ways:

1. Introduce a v2 Service object, where EffectiveAddress/EffectivePort is augmented by zero or more Endpoints that are part of Status, supporting all service modes, with all the Kubernetes forward/backward storage shimming.
2. Introduce a different object type, e.g. `Service2`, still supporting all the service modes, but replacing EffectiveAddress/EffectivePort with Endpoints list.

IMO microsoft/usvc#2 is sufficient and less work, but we probably need more discussion around this.

CC @ReubenBond

Start with the Service model described here, including EffectiveAddress/EffectivePort and the Endpoints status property, then read microsoft/usvc#2 and compare the proposed v2 object and Service2 alternatives. Done requires an agreed API and compatibility design for unlimited endpoints and client-side routing; the issue does not identify implementation files or tests.

Written by the indexing model from the issue text.