Add load-balancing config to default client dial options

For #4530 (closed), this is a replacement of Auto-generate load-balancing policy and auto-re... (!5227 - closed)

This MR adds client-side load-balancing to Gitaly clients. The default load-balancing strategy is set to "round-robin". When gRPC client establishes a connection, if it detects, there are more than 1 subchannels after name resolution, it starts to distribute the requests to the subchannels in a round-robin fashion. Any connectivity changes are detected and handled transparently at the library layer. The corrupted subchannel is removed, and subsequent requests are evicted to other active subchannels. For more information about how client-side load-balancing works, please read this comment.

This load-balancing strategy is configured via Service Config. The service config can be configured statically when dialing or dynamically via TXT DNS Record. The dynamic approach doesn't make sense for Gitaly. Even worse, it may cause unexpected failure. As a result, this MR exposes the service config via WithDefaultLoadBalancing dial option. The client can opt in by adding this option when dialing to the host. This approach also reduces the risks comparing to adding this option by default for all clients. The downside is that we must upgrade and add this option to all clients.

As opposed to the prior version (!5227 (closed)), this MR leaves the auto-retry policy out of the picture. We detected multiple places where Gitaly sets the status code inaccurately. It's not safe to assume we can retry read-only requests based on the returned status codes.