Adding a tag to identify OkHttp calls made from OTel exporters

[LikeTheSalad]

Related to #5886

After deciding to use an internal solution in the previous SIG, and also raising concerns about the usage of a Context key due to performance penalties, I believe this approach is the most straightforward and stable way to identify OTel's OkHttp calls for internal, automatic instrumentation purposes, since it doesn't need to use Context keys, nor does it need to rely on Thread's values propagation or intercepting threads that OkHttp will use for async calls (in case of using ThreadLocals) or relying on the thread's name, since it seems like it's being changed before running OkHttp's interceptors, which is where the automatic traces are created.

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Files	Coverage Δ
...orter/sender/okhttp/internal/OkHttpGrpcSender.java	78.88% <100.00%> (ø)
...orter/sender/okhttp/internal/OkHttpHttpSender.java	98.43% <100.00%> (ø)
...ry/exporter/sender/okhttp/internal/OkHttpUtil.java	100.00% <100.00%> (ø)
.../fileconfig/OpenTelemetryConfigurationFactory.java	100.00% <100.00%> (ø)
...ension/incubator/fileconfig/PropagatorFactory.java	100.00% <100.00%> (ø)
...incubator/fileconfig/TextMapPropagatorFactory.java	100.00% <100.00%> (ø)

📢 Thoughts on this report? Let us know!.

[LikeTheSalad]

Replaced by: #5918