Audit xDS structures emitted to envoy for request-to-request stability

We recently identified at least two places (https://github.com/hashicorp/consul/pull/9651 & https://github.com/hashicorp/consul/pull/9650) where two xDS discovery requests from envoy with otherwise unchanged effective content would be shipped in a slightly different internal ordering to envoy.

In some of these cases, envoy treats these as requiring a wholesale replacement of the underlying structures, rather than a no-op. For listeners this is particularly bad because depending upon the nature of the change it might have to drain traffic and close open sockets to correct.

We should audit all of the paths to produce xDS structures (EDS, CDS, LDS, RDS) to ensure that any deduplication process, list construction, etc is deterministic.

- For deduplication, ensure that regardless of how the duplicates are traversed we always select the same winner
- For list construction within an envoy object, ensure that there is a known order. For example, if filter chains are known to be independent we still need to render them into the overall list of filter chains in a specific order so ensure they go in the same order each time.

One notable thing we can ignore is the order of "x" items in an individual "xDS" resource response. For example if we emit 4 listeners to an LDS request, those don't have to be in any particular order.