Change azure_ and az. to azure. across all conventions

[lmolkova]

Azure-specific attributes/signals use azure. prefix to denote they belong to azure namespace.

We should

• Consolidate cloud.platform enum values:
  • azure_aks -> azure.aks
  • azure_app_service -> azure.app_service
  • azure_container_apps -> azure.container_apps
  • azure_container_instances -> azure.container_instances
  • azure_functions -> azure.functions
  • azure_openshift -> azure.openshift
  • azure_vm -> azure.vm
• Consolidate gen_ai.system enum values:
  • az.ai.inference -> azure.ai.inference
  • az.ai.openai -> -> azure.ai.openai
• Azure SDK attributes
  • az.namespace -> azure.resource.namespace
  • az.service_request_id -> azure.service.request.id
• Azure log event
  • az.resource.log -> azure.resource.log

Related to #1684 (comment), #608, #1708, #1613

PS: We should do similar renames for AWS and GCP, cloud.provider -> cloud.provider.name, cloud.platform -> ?

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]

/cc @trask, @mattmccleary, @rajkumar-rangaraj, @cijothomas, @lzchen @RohitRanjanMS, @OsvaldoRosado, @reyang if the have any context on how breaking they expect it to be.

[RohitRanjanMS]

Thanks, @lmolkova . Functions is still in its early stages with respect to OTel, and I don't see any issues with this proposal.

[lzchen]

We do have azure resource detector that use some of these values although the component itself is experimental. In azmon exporter, we currently do not map resource attributes to telemetry custom dimensions BUT we do populate OTELRESOURCE custom metric which is populated with the resource attribute information. I believe this feature is in preview as well so probably not an issue to make breaking changes.

@jeremydvoss

[lmolkova]

Alternatives:

• azure.provider.namespace
• azure.resource.provider.namespace - precise, but too long
• azure.rp.namespace - this acronym is likely to be MS-internal thing

[lmolkova]

Alternatives:

• azure.server.request.id (there is also azure.client.request.id counterpart not documented here) - this aligns with semconv better, but service gives a nuance that it's generated by the Azure service, while server is used in semconv more the context of user app

[lmolkova]

oops