Change API request impls to favor lists and linkedhashsets on interfaces

[michael-mclawhorn]

We should support eTag to permit client side caching of metadata where appropriate.

In most cases metadata ApiRequests are good enough to determine whether or not a request is deterministic. (taking into account state mutable after config like availability as an exception) As such the natural element to use to generate the eTag hash (or to generate MOST of the eTag hash) is the ApiRequest.

However right now there is no interface guarantee that Sets of Tables, Metrics, Dimensions, etc. will have a durable ordering across requests. If we change the surface of the ApiRequest elements to reflect an expectation of ordering (changing to either LinkedHashSet or List as appropriate), then we can more efficiently build hashes.

This would be a partial breaking change (on getters) and a few non primary constructors:

Change Set<[ApiElement]> to LinkedHashSet<[ApiElement]> wherever reasonable on the ApiRequest subclasses.

It is also a little inefficient to be using Set since Interval has a natural ordering, and Sets have more expensive comparation and insertion.

So change instances of:
Set in all the interfaces to be List.

This also allows us to swap in SimplifiedIntervalList where ever appropriate.

[kevinhinterlong]

@michael-mclawhorn should #754 close this and then add a new issue about eTag?

[michael-mclawhorn]

Fixed