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.

Commencez par suivre le traitement côté worker pour PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY et comparez-le au comportement documenté de PYTHON_ENABLE_OPENTELEMETRY et de telemetryMode dans host.json. Examinez l’onglet de documentation OTLP-Python et le chemin azure.monitor.opentelemetry.configure_azure_monitor(). C’est terminé lorsque les exportateurs OTLP côté worker respectent les variables d’environnement OTEL indiquées, que les tests couvrent la matrice de comportement et que la documentation officielle décrit la configuration sans code.

Rédigé par le modèle d'indexation à partir du texte de l'issue.