Move retry code into its own filter in the DynamicFilter stack

[markdroth]

This is the restructuring of the client channel filter that I mentioned in #25791. The main change is to move the retry code to its own filter in the DynamicFilter stack, but it also moves the definition of the client channel filter's channel data class into the .h file, which makes it easier to interact with it from other places.

Prior to this PR, the final filter in the DynamicFilter stack was always the DynamicTerminationFilter, which would check whether retries were enabled and then create either a LoadBalancedCall or a RetryingCall (which would internally create a LoadBalancedCall for each retry attempt). In other words, the flow was one of these two, depending on whether retries were enabled:

Retries enabled: DynamicFilters -> DynamicTerminationFilter -> RetryingCall -> LoadBalancedCall
Retries disabled: DynamicFilters -> DynamicTerminationFilter -> LoadBalancedCall

This PR moves the RetryingCall code into an alternative version of the DynamicTerminationFilter that performs retries, and the client channel filter decides whether to use the DynamicTerminationFilter or the RetryFilter based on whether retries are enabled. So the flows now look like this:

Retries enabled: DynamicFilters -> RetryFilter -> LoadBalancedCall
Retries disabled: DynamicFilters -> DynamicTerminationFilter -> LoadBalancedCall

Please let me know if you have any questions.

[veblush]

Thank you for the refactoring. I mostly focused on the code structure rather than its implementation, assuming this doesn't change retry logic much.

[markdroth]

Known issues: #25856