otelgrpc: Deprecate interceptors in favor of stats handlers

[pellared]

Fixes #4318

We strongly still recommend you to use stats.Handler, mainly for two reasons.

Functional advantages: stats.Handler has more information for user to build more flexible and granular metric, for example:

• multiple different types of represent "data length": In stats.InPayload, there exists "Length", "CompressedLength", "WireLength" to denote the size of uncompressed, compressed payload data, with or without framing data. But in interceptors, we can only got uncompressed data, and this feature is also removed due to performance problem.
• more accurate timestamp: stats.InPayload's "RecvTime" and stats.OutPayload's "SentTime" records more accurate timestamp that server got and sent the message, the timestamp recorded by interceptors depends on the location of this interceptors in the total interceptor chain.
• some other use cases: for example, catch failure of decoding message.

Performance advantages: If too many interceptors are registered in a service, the interceptor chain can become too long, which increases the latency and processing time of the entire RPC call.

[pellared]

@fatsheep9146 Could you please review this PR?

[codecov]

Codecov Report

Merging #4534 (245089d) into main (a3b16ae) will decrease coverage by 0.1%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            main   #4534     +/-   ##
=======================================
- Coverage   80.8%   80.8%   -0.1%     
=======================================
  Files        150     150             
  Lines      10371   10371             
=======================================
- Hits        8387    8384      -3     
- Misses      1840    1842      +2     
- Partials     144     145      +1     

Files	Coverage Δ
...entation/google.golang.org/grpc/otelgrpc/config.go	69.6% <ø> (ø)
...ion/google.golang.org/grpc/otelgrpc/interceptor.go	87.0% <ø> (-0.8%)	⬇️