feat(agents): support OpenTelemetry metrics

[Fant1k34]

Motivation and Context

PR introduces metrics support based on OpenTelemetry specification. Such metrics allow their listeners observe the behaviour of agent in run-time. All changes are done within OpenTelemetry feature

Link to issue

Added configuration:

• addMeterExporter(MetricExporter) -- function within OpenTelemetry feature that accept MetricExporter and sent library metrics via such exporter

Example of OpenTelemetry feature configuration:

install(OpenTelemetry) {
    setServiceInfo(
        "calculator",
        "0.0.1"
    )
    addResourceAttributes(
        mapOf(AttributeKey.stringKey("service.instance.id") to "run-1")
    )
    addMeterExporter(
        OtlpGrpcMetricExporter.builder()
            .setEndpoint("http://localhost:17011")
            .setTimeout(1, TimeUnit.SECONDS)
            .build()
        )
    }

Added metrics:

• gen_ai.client.token.usage -- see here
• gen_ai.client.operation.duration -- see here
• gen_ai.client.tool.count -- custom metric allows observe tool calls and their statuses

Visualisation (via OpenTelemetry plugin):

Breaking Changes

---

Type of the changes

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Tests improvement
• Refactoring
• CI/CD changes
• Dependencies update

Checklist

• The pull request has a description of the proposed change
• I read the Contributing Guidelines before opening the pull request
• The pull request uses develop as the base branch
• Tests for the changes have been added
• All new and existing tests passed

Additional steps for pull requests adding a new feature

• An issue describing the proposed change exists
• The pull request includes a link to the issue
• The change was discussed and approved in the issue
• Docs have been added / updated

[sdubov]

I like the consistency for current metrics support implementation. Thank you. Please check my comments about some metrics implementation details.

[sdubov]

As we discussed, I have two concerns here:

1. restricToolNameCardinality config which I found a bit confusing. As I noticed, I would implement this as an extension for a metric adapter (similar to the span adapter).
2. Single responsibility for MetricCollector class. I would prefer it to be able to track any metric and help to create it if needed (keep the timestamp for a start event if needed for now).

Other than that, looks good for me. We can address some of those questions later in a further commits. For now, I will approve this one to not block the development.