Add an OpenTelemetry (OTLP/HTTP) tracing provider so traces can be exported to any OTel backend

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] Please do not modify this template :) and fill in all the required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

I self-host Dify and my observability stack already speaks OpenTelemetry: our traces live in Jaeger / Grafana Tempo / SigNoz or a plain OTel Collector pipeline, all ingesting OTLP over HTTP. I wanted Dify's workflow and chatflow traces to land in that same backend so LLM-app traces sit next to our service traces, but the Tracing panel in Dify only offers a fixed provider list (LangSmith, Langfuse, Phoenix, etc.). If your exact vendor is not on the list, there is no way to point Dify at a plain OTLP endpoint — I was trying to use Dify tracing with my own collector for debugging agentic workflows, and the config simply has no entry for it. It was frustrating because Dify already standardizes spans internally through the provider-neutral unified tracing runtime (#39451), so a generic OTel collector is the only missing door. This was also asked for before in #25113.

### 2. Additional context or comments

What I'd love to see (and am happy to help build):

- A generic **OpenTelemetry** option in the Tracing panel that exports to any OTLP/HTTP endpoint: an otel-collector, Jaeger, Grafana Tempo, SigNoz, Elastic, or vendor agents that accept OTLP.
- Provider-level settings: endpoint URL (e.g. `http://collector:4318/v1/traces`), auth headers (kept as secrets), `service.name`, and arbitrary resource attributes.
- Built on the unified tracing runtime merged in #39451, so span hierarchy, retry semantics, and cross-task parent coordination stay consistent with the other unified providers, instead of growing yet another bespoke hierarchy implementation per provider.

### 3. Can you help us with this feature?

- [x] I am interested in contributing to this feature.

Start with the Tracing panel and the provider configuration, then read the unified tracing runtime referenced in #39451 and compare its existing unified providers. The work is done when a generic OTLP/HTTP option accepts an endpoint, secret auth headers, service.name, and resource attributes while preserving the runtime's span hierarchy, retry semantics, and cross-task parent coordination.

Written by the indexing model from the issue text.