ClientModel: Address extensibility for IsRetriable to validate that is additive after v1.

[annelo-msft]

Understand how we would add the ability for end-users to specify what Azure.Core supports in the ResponseClassifier.IsRetriable API today, to ensure we have the correct design for PipelineMessageClassifier.

@tg-msft FYI

[annelo-msft]

Related to #41320

[annelo-msft]

The problem we have today in Azure.Core is that if a client-author provides a client-scoped ResponseClassifier and the generated protocol method provides a method-scoped ResponseClassifier, since classifiers are not composable, we don't know how to choose which one to apply when we call classifier.IsRetriable(message) in the retry policy.

We addressed this problem for ResponseClassifier error classification by adding AddClassifier methods to RequestContext that allow either adding a status code classification into the generated method-scoped classifier, or adding a ResponseClassificationHandler to a chain of classifiers, where each handler designates both whether it wants to classify the message and then, if it does, the message "is error response" classification. The order of the handlers in the chain allows us to let end-user classification handlers take precedence over generated classifier logic, while preserving the generated classifier logic where the handler doesn't have an opinion.

The above solves the composability problem for error classification, but does not solve it for composition of retriability. And, in fact, I think it points to a challenge where we've named the error-classification APIs on RequestContext in such a way that they may imply classifiers are only applicable to error-response classification and response-retry classification. Maybe we can find a way out of that.

In System.ClientModel, though, I think we can solve this similar to how we've said we'll address the addition of error-classifiers in #41320. We can choose to add IsRetriable to PipelineMessageClassifier -- we know from the Azure.Core ResponseClassifer APIs that the name of IsErrorResponse will allow the addition of multiple IsRetriable* methods, where the base class provides a default implementation for each. What we might want to do differently in ClientModel's RequestOptions when we add composability of both error classifiers and retry classifiers is name rename the AddClassifier methods to AddErrorClassifier and AddRetryClassifier. We retain the public MessageClassifier property on PipelineMessage, and it remains the client-author's responsibility to compose classifiers before setting this value on the message -- for both error classification AND retry classification -- and we should be careful that we don't allow a MessageClassifier to be specified in PipelineOptions per this comment.

[annelo-msft]

Ah, it looks like we may still need validation that the ChainingClassifier implementation would work if MessageClassifier had both error and retry classification logic.

[annelo-msft]

Closed by #41586