RPC: deprecate rpc.server|client.request|response.size metrics

[lmolkova]

Fixes #3259

Deprecate rpc.server.request.size, rpc.server.response.size, rpc.client.request.size,
and rpc.client.response.size metrics due to confusing definition and low adoption.

Came up in #3229 when analyzing gRPC native metrics.

• these metrics have confusing names: they use request|response terminology, but apply to individual messages within a stream. E.g. Java instrumentation interprets them as per-call (and records metrics with last-message-size while Go instrumentation reports metric per-message)
• it's not clear if these metrics should be recorded on retries, when messages are resent - if not, they no longer sum up to throughput and become even more confusing.
• I could not find implementations of these metrics beyond Go and Java in OTel ecosystem.
• gRPC native metrics define grpc.client.attempt.sent_total_compressed_message_size, grpc.client.attempt.rcvd_total_compressed_message_size, grpc.server.call.sent_total_compressed_message_size, grpc.server.call.rcvd_total_compressed_message_size which are more specific.

Retries and compression are framework/protocol specific and following T-Shaped signals philosophy, each framework can define its own metrics for message sizes when necessary.

If there is enough commonality, new metrics can be added to OTel in the future, but we're not targeting them for initial RPC conventions stability.

[trask]

@open-telemetry/java-instrumentation-approvers any concerns with us removing these metrics?