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.

Inizia tracciando la gestione da parte del worker di PYTHON_APPLICATIONINSIGHTS_ENABLE_TELEMETRY e confrontala con il comportamento documentato di PYTHON_ENABLE_OPENTELEMETRY e telemetryMode in host.json. Esamina la scheda della documentazione OTLP-Python e il percorso azure.monitor.opentelemetry.configure_azure_monitor(). Il lavoro è completato quando gli exporter OTLP lato worker rispettano le variabili di ambiente OTEL elencate, i test coprono la matrice dei comportamenti e la documentazione ufficiale descrive la configurazione senza codice.

Scritto dal modello di indicizzazione a partire dal testo della issue.