V3: Clarify relationship between APIs and Endpoints

[EricBurnett]

As discussed in https://github.com/bazelbuild/remote-apis/pull/116 , and previous places.

The REAPI currently does not specify what APIs and resources must be accessible from the same endpoint (domain), and what are able to be independently varied. For example, hosting the Execution API on a different endpoint from the CAS. A few clients currently support varying the endpoints along specific bounds, but not all consistently with each other, and no client allows full flexibility in how APIs/resources and endpoints can be paired. This ambiguity routinely comes up and causes problems for implementers.

There are two directions I see that we could go as a community. One is to say that clients should expect all APIs available at a single endpoint, period. The other is to define a clear set of different 'virtual' endpoints (Service APIs, perhaps scoped to a particular set of resources, e.g. like the Execution service, plus 'CAS blob bytestreams', 'streamed bytestreams', etc), specify how they're bucketed in terms of which are allowed to vary independently and which should be co-hosted, and recommend a consistent way to configure clients and/or let them discover it.

The Capabilities API will also need to be revised in light of whatever is decided here.

cc @edbaunton @sstriker

[dgassaway]

Carrying over from previous discussion, in the Scoot we chose to serve the APIs from different service components that delineated cleanly along the separate service designations in the proto def. It was far simpler in our case to use client flags to route requests to the right services rather than implement a server side proxy mechanism.