Switch C# to contextual serializer and deserializer internally

[jtattermusch]

contextual (de)serializers have been introduced in #16367.
Serialization performance stays the same, but the switch is a foundation for introduction of more efficient serialization is in progress in #16371

[grpc-testing]

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,019,040      Total (=)      2,019,040

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,179,730      Total (<)     11,179,733

 No significant differences in binary sizes

[apolcyn]

looks mostly good, a couple of minor nits

[apolcyn]

just wondering: why was this switched from abstract to having a default that's just unusable? Any DeserializationContext that doesn't implement this wouldn't work, no?

[jtattermusch]

This has been done with the idea that in the future more methods will be added (e.g. to access the payload with more efficiency) and when added, they will be added as virtual methods with a default implementation so that the backward compatibility is not broken (=classes inheriting from DeserializationContext won't break if they don't provide implementation for all methods).
So I changed the method to virtual with default implementation mostly for consistency with the methods that will be added in the future.

[apolcyn]

same comment here as for the abstract -> default-throws comment on DeserializationContext above.

[jtattermusch]

Same as above

[apolcyn]

can we just get rid of the serializer and deserializer fields entirely, since they are no longer used now?

[jtattermusch]

We need to keep the Serializer and Deserializer properties to maintain backward compatibility.
And the other constructor is setting the serializer and deserializer fields.

[jtattermusch]

@apolcyn responded to concerns, PTAL.

[jtattermusch]

Known failures: #17170