Add system-specific naming guidance

[lmolkova]

Fixes #1494

Related:

• Change azure_ to az. in cloud.platform enum values on #1698

Documents:

• Systems-specific attribute names follow {optional domain}.{system} pattern
• Systems-specific metric names follow {domain}.client|server.{system} or {system}.client|server pattern
• Metrics for network operations should include some indication if they are client or server

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[lmolkova]

the difference with signalr.server.connection.duration below makes me think if we should simplify it and do cosmosdb.client.operation.request_charge. What's the benefit of having db in front of it?

[lmolkova]

summoning @open-telemetry/semconv-system-approvers

It's the same question as for system.linux vs linux metrics in #1403 or #1618

[lmolkova]

Similar to https://github.com/open-telemetry/semantic-conventions/pull/1708/files#r1894523030

what's the benefit of having db in front of cassandra here? why not cassandra.consistency_level?

[lmolkova]

Let's say we have some redis-specific attributes (and redis can be used as a DB and as a messaging system), would we define db.redis and messaging.redis ? probably not, it should be just redis.