Add dual-semconv support to RPC metrics

[zeitlinger]

Part of #15932 — split into smaller reviewable PRs. This is PR 4 of 5 (depends on #16130).

• Add stable metric rpc.client.call.duration (seconds) alongside old rpc.client.duration (milliseconds)
• Add stable metric rpc.server.call.duration (seconds) alongside old rpc.server.duration (milliseconds)
• Update RpcMetricsAdvice with separate old/stable attribute key lists (rpc.system.name, rpc.response.status_code for stable)
• Add OLD_RPC_METHOD_CONTEXT_KEY infrastructure for correct rpc.method handling in dup mode
• Size metrics (rpc.*.request.size, rpc.*.response.size) remain old-only
• Tests validate all three modes: old-only, stable-only, and dup

#15871

[zeitlinger]

@trask In #15932 you commented that under rpc/dup, stable semconv should take priority and there's no need for this extra context key.

The reason it exists: in dup mode, both old and stable metrics use the same rpc.method attribute key but with different values — old uses just the method name ("exampleMethod"), stable uses "service/method" format ("myservice.EchoService/exampleMethod"). Since both values live in the same Attributes object, stable wins and overwrites old.

Without this context key, the old rpc.server.duration / rpc.client.duration histograms would report rpc.method = "myservice.EchoService/exampleMethod" instead of "exampleMethod" — a breaking change for anyone querying old metrics during migration (which is the whole point of dup mode).

The context key is never emitted — it just passes the old method value through Context so the metrics classes can swap it back when recording to old histograms.

Happy to drop this if you think letting the values clash in dup mode is acceptable. Just wanted to make sure the trade-off is clear.

[trask]

thanks, it makes sense to me