.NET proxy should populate route details to current `Activity` for tracing purposes

### Is your feature request related to a problem? Please describe the problem.

When using standard tracing practices and libraries (in .NET space, OpenTelemetry plus native ASPNETCore trace instrumentation), we get rich details on requests received on the server: the route for the action is used to generate the span so we can get isolated data for each "resource" in the API. The trace would have a name such as `POST /api/entities`.

However, this type of detailed information is completely missing when making _outgoing_ http calls via `kiota`. Instead, the only information we see on outgoing telemetry spans is the HTTP method and nothing else.

This would make sense for a raw `HttpClient`-based integration, since the client has zero information about what it is interfacing with. But with `kiota`, the information is easily extracted from the OpenAPI document it uses to generate the code, so it should be possible for the library to pass that information in to the current telemetry scope.

This proposal is to request the team to include route and other related information when making calls via `kiota`-generated .NET proxies by appending that information to the current `Activity` (if it is available) so that we get rich tracing information for outgoing calls the same way we get for incoming ones.

Detailed OpenTelemetry specs for HTTP spans in case you need a reference as to what data can be used and how to name it:
- https://opentelemetry.io/docs/specs/semconv/http/http-spans/

The `route` is an obvious and important gap, but I'm sure there are other properties that could also be used to enrich traces.

### Client library/SDK language

Csharp

### Describe the solution you'd like

I would like for .NET `kiota` proxies to propagate routing information and other metadata that it gets from the OpenAPI spec as `Activity` span data, so that we get richer tracing telemetry for outgoing calls similar to the ones we already get with standard integrations for incoming calls.

### Additional context

Our team interfaces with many different external vendors via HTTP, and we would like to more closely monitor specific calls to those vendors including specific routes and parameters. By having `kiota` itself instrument the calls with the data it obtains from the source generation from the OpenAPI spec we would not need to add any custom logic to improve that traceability.

We additionally use Datadog today which would be able to auto-generate APM metrics in a more granular fashion out of those better-instrumented outgoing HTTP calls, allowing us to group and aggregate data on a per-vendor and per-resource basis.

Begin with the .NET Kiota proxy path that creates outgoing HTTP calls and inspect how the current Activity is accessed. Compare the route and other metadata available from the OpenAPI document with the OpenTelemetry HTTP span specification. Done means outgoing proxy spans expose useful route details and related metadata without requiring custom instrumentation.

Written by the indexing model from the issue text.