RetryPriority plugin not supported for RING_HASH/MAGLEV

`RING_HASH` and `MAGLEV` both support priority routing, but does not honor `LoadBalancerContext::determinePriorityLoad`, effectively breaking the `RetryPredicate` plugins. This also has implications wrt https://github.com/envoyproxy/envoy/pull/7967, as it attempts to target a specific priority using the LB context.

Calling `determinePriorityLoad` is tricky in the context of `ThreadAwareLoadBalancer` due to the LBs not having access to the `PrioritySet` used to compute the priority loads that it uses: only the necessary information is currently snapped into the TLS load balancer, which does not include the entire `PrioritySet`.

Some options:
1) Pull the `PrioritySet` from the TLS cluster. This is probably the simplest solution, but means that the `PrioritySet` might be out of sync with the priority loads stored on the `ThreadAwareLoadBalancer`: there might have been another change to the priority loads on the main thread before any given change is propagated to the TLS cluster. For example, if two updates happen right after each other, a request that gets handled between the two dispatcher events to update the TLS cluster might be using the TLS cluster after the first update but the priority loads after both updates.
2) Store additional data in the the LB factory, sufficient to recreate the `PrioritySet` on the worker threads and pass it to the LB context. The `PrioritySetImpl` itself cannot be shared between threads due to being mutable.
3) Add an overload to `determinePriorityLoad` that doesn't accept a `PrioritySet`. This wouldn't make the ThreadAware LBs compatible with the `RetryPriority` plugins, but would at least allow for the aggregate cluster to target a specific priority.

Open to other suggestions as well.

@yxue