Major client performance refactor

[JamesNK]

• Cache Uri and call scope for methods on channel
• Hardcode GrpcCall logger name to avoid reflection
• Reduce async state machines allocated
• Switch from Task to ValueTask where possible
• Reuse System.Version
• Optimize content-type validation
• Optimize fields on GrpcCall
• Create PushUnaryContent and PushStreamContent

[JamesNK]

Before:

          Method |     Mean |     Error |    StdDev |      Op/s | Gen 0/1k Op | Gen 1/1k Op | Gen 2/1k Op | Allocated Memory/Op |
---------------- |---------:|----------:|----------:|----------:|------------:|------------:|------------:|--------------------:|
 HandleCallAsync | 8.806 us | 0.0673 us | 0.0630 us | 113,559.3 |      1.3733 |           - |           - |             5.66 KB |

After:

          Method |     Mean |     Error |    StdDev |      Op/s | Gen 0/1k Op | Gen 1/1k Op | Gen 2/1k Op | Allocated Memory/Op |
---------------- |---------:|----------:|----------:|----------:|------------:|------------:|------------:|--------------------:|
 HandleCallAsync | 6.023 us | 0.1185 us | 0.1499 us | 166,036.8 |      1.0681 |           - |           - |             4.38 KB |

[jtattermusch]

I skimmed through the PR and generally looks ok, but I'd still like @JunTaoLuo to give a final LGTM after reviewing more in detail.

[jtattermusch]

not sure I recall this correctly, but the concurrentDictonary tends to allocate even in situations when one doesn't expect that, so if the purpose of the cache is to save allocations of new GrpcMethodInfo instances, then this might only be a partial solution.

[JamesNK]

Could you be more specific?

I cached the delegate used with GetOrAdd in a field _createMethodInfoFunc so it is allocated once per channel, rather than once per call. Other than that I didn't notice additional allocations.

[JunTaoLuo]

Still digesting some of the GrpcCall changes. Will finish the review tomorrow.

[JunTaoLuo]

Looks clean!