Add PYTHON_ENABLE_OPENTELEMETRY worker-side auto-init for OTLP exporters (symmetric to PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY)

### Binding Type

Not specific to a binding; this is an environment-based worker auto-init request affecting overall telemetry/diagnostics experience.

### Expected Behavior

When telemetryMode: OpenTelemetry is set in host.json and APPLICATIONINSIGHTS_CONNECTION_STRING is not present, setting PYTHON_ENABLE_OPENTELEMETRY=true (documented for the OTLP tab in the official docs) should cause the worker to *auto-initialize a TracerProvider+LoggerProvider with OTLP exporters*, respecting the standard OTel env vars:
- OTEL_EXPORTER_OTLP_ENDPOINT
- OTEL_EXPORTER_OTLP_HEADERS
- OTEL_SERVICE_NAME
- OTEL_RESOURCE_ATTRIBUTES
- OTEL_TRACES_EXPORTER, OTEL_LOGS_EXPORTER, OTEL_METRICS_EXPORTER

This mirrors the current experience of PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY, which invokes azure.monitor.opentelemetry.configure_azure_monitor() and provides a zero-code path. This request is for worker-level parity for OTLP exporters: PYTHON_ENABLE_OPENTELEMETRY=true should set up and wire everything so the user does not need any code to export logs, traces, and metrics to OTLP endpoints.

### Relevant sample code snipped

```shell
Current workaround (for each app):

import os
if os.environ.get("PYTHON_ENABLE_OPENTELEMETRY") == "true" and "APPLICATIONINSIGHTS_CONNECTION_STRING" not in os.environ:
from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor, OTLPSpanExporter
from opentelemetry.sdk.logs import LoggerProvider
from opentelemetry.sdk.logs.export import BatchLogRecordProcessor, OTLPLogExporter
trace.set_tracer_provider(
TracerProvider(
resource=Resource.create(), # env picks up OTEL_RESOURCE_ATTRIBUTES, etc.
)
)
trace.get_tracer_provider().add_span_processor(
BatchSpanProcessor(OTLPSpanExporter())
)
logger_provider = LoggerProvider(resource=Resource.create())
logger_provider.add_log_record_processor(
BatchLogRecordProcessor(OTLPLogExporter())
)

Expected: When PYTHON_ENABLE_OPENTELEMETRY=true and OTEL_EXPORTER_OTLP_ENDPOINT is present (and no App Insights connection string), this code path should be automatic. No user code needed.
```

### Additional Information

Summary
When telemetryMode: OpenTelemetry is set in host.json and APPLICATIONINSIGHTS_CONNECTION_STRING is configured, setting PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY=true causes the worker to auto-invoke azure.monitor.opentelemetry.configure_azure_monitor(); users get a fully wired worker with zero code.

There is no equivalent for the OTLP-exporter path. PYTHON_ENABLE_OPENTELEMETRY=true (documented for the OTLP tab) only affects the host process, not worker-side auto-wiring. The OTLP-Python doc tab currently instructs users to write their own LoggerProvider + OTLPLogExporter + BatchLogRecordProcessor setup.

This is surprising, as both env vars look like sibling switches but only one actually configures the worker SDK.

Motivation / Use case
- .NET Aspire orchestrates local dev for distributed apps and injects OTEL_EXPORTER_OTLP_ENDPOINT. Stock OTel auto-init in .NET/Node/Python picks this up for zero-code pipelines. Functions Python is the outlier: users must hand-write the SDK bootstrap and keep it in sync with the prod (App Insights) path. This applies to all non-App-Insights backends (Datadog, Tempo, New Relic, etc.).

Proposed behavior matrix
| Env vars set | Current worker behavior | Proposed worker behavior |
|--------------|------------------------|--------------------------|
|PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY=true + APPLICATIONINSIGHTS_CONNECTION_STRING|Auto-calls configure_azure_monitor()|Unchanged|
|PYTHON_ENABLE_OPENTELEMETRY=true + OTEL_EXPORTER_OTLP_ENDPOINT|No-op in worker (host only)|Auto-wires SDK with OTLP exporters|
|Both|Azure Monitor wins|Dual export (matches host behavior)|

References
- Docs: https://learn.microsoft.com/azure/azure-functions/opentelemetry-howto?tabs=python (see OTLP-Python tab)
- Sibling host setting: telemetryMode: OpenTelemetry in host.json
- Distro used in App Insights path: azure-monitor-opentelemetry (see source)

Acceptance Criteria
- A documented env-var switch (or extend the existing PYTHON_ENABLE_OPENTELEMETRY) that makes the worker auto-wire an OTLP-exporting SDK.
- Official docs updated so OTLP-Python can match the App Insights 'set one env var' simplicity.
- Tag Azure/azure-functions-host (owns host telemetryMode/host-side OTLP) and MicrosoftDocs/azure-docs for visibility on related behaviors and documentation coverage.

まず、PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY に対する worker の処理を追跡し、文書化されている PYTHON_ENABLE_OPENTELEMETRY および host.json の telemetryMode の動作と比較します。OTLP-Python のドキュメントタブと azure.monitor.opentelemetry.configure_azure_monitor() のパスを確認します。worker 側の OTLP exporter が一覧にある OTEL 環境変数に従い、テストが動作マトリクスを網羅し、公式ドキュメントでゼロコードのセットアップが説明されていれば完了です。

索引モデルが issue の本文から書いたものです。