Remove misleading implementation guidance for context propagation via environment variables (#5003)

Per
#4961 (comment)
and other similar feedback

## Changes

This PR removes the non-normative guidance that presented a dedicated
`EnvironmentContextPropagator` as a first-class alternative for
environment variable context propagation.

The supplementary guidance now describes the carrier-based pattern
directly:

- use the existing `TextMapPropagator` with environment-specific
carriers (`EnvironmentGetter` and `EnvironmentSetter`)
- reference the existing C++, Go, Java, and Python implementation (I
also created a PR for Swift that follows the same pattern
open-telemetry/opentelemetry-swift-core#47)

The previous (removed) “Approach 1” guidance suggested that a dedicated
environment-variable-specific propagator was a viable recommendation.
Based on the discussion in #4961, that approach is seen as
misleading/buggy:
- the environment variable carrier should remain format-agnostic
- propagator-specific behavior belongs in the propagator, not in the
carrier
- the Swift example did not reflect the direction we want to recommend
here

This change keeps the document aligned with the carrier-based model used
by the referenced implementations.

## Side note

I think we can look into stabilization of this document after this PR is
merged. I plan to create a stabilization issue and update the compliance
matrix.

---------

Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>

Author: pellared

CHANGELOG.md

@@ -14,6 +14,8 @@ release.
   ([#4914](https://github.com/open-telemetry/opentelemetry-specification/issues/4914))
 - Decouple the responsibilities of the environment variable propagation carrier.
   ([#4961](https://github.com/open-telemetry/opentelemetry-specification/issues/4961))
+- Remove misleading implementation approach the environment variable propagation.
+  ([#5003](https://github.com/open-telemetry/opentelemetry-specification/issues/5003))
 
 ### Traces
 

specification/context/env-carriers.md

@@ -15,9 +15,6 @@
     + [Process Spawning](#process-spawning)
     + [Security](#security)
 - [Supplementary Guidelines](#supplementary-guidelines)
-  * [Approach 1: Providing a dedicated `EnvironmentContextPropagator`](#approach-1-providing-a-dedicated-environmentcontextpropagator)
-  * [Approach 2: Using the carriers directly through `Setters` and `Getters`](#approach-2-using-the-carriers-directly-through-setters-and-getters)
-  * [Common Behaviors](#common-behaviors)
 
 <!-- tocstop -->
 
@@ -117,23 +114,9 @@ process and with the correct permissions, can be accessed from other processes.
 > guidance only. It does not add requirements to the specification.
 
 Language implementations of OpenTelemetry have flexibility in how they implement
-environment variable context propagation. Two main approaches have been
-identified as viable.
-
-### Approach 1: Providing a dedicated `EnvironmentContextPropagator`
-
-SDKs can create a dedicated propagator for environment variables. For example,
-the [OTel Swift][swift] implements a custom `EnvironmentContextPropagator` that
-handles the environment-specific logic internally, in essence decorating the
-`TextMapPropagator`.
-
-[swift]: https://github.com/open-telemetry/opentelemetry-swift-core/blob/c84cdc1760e20fc3a448c4e8aaae490f7d48ac67/Sources/OpenTelemetrySdk/Trace/Propagation/EnvironmentContextPropagator.swift
-
-### Approach 2: Using the carriers directly through `Setters` and `Getters`
-
-Language implementations can use the existing `TextMapPropagator` interface directly with
-environment-specific carriers. Go and Python SDKs follow this pattern by
-providing:
+environment variable context propagation. Language implementations can use the
+existing `TextMapPropagator` directly with environment-specific carriers.
+Typically implementations follow this pattern by providing:
 
 - `EnvironmentGetter` - creates an in-memory copy of the current environment
   variables and reads context from that copy.
@@ -151,15 +134,3 @@ Examples:
 [gi]: https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/propagators/envcar
 [ji]: https://github.com/open-telemetry/opentelemetry-java/tree/main/api/incubator/src/main/java/io/opentelemetry/api/incubator/propagation
 [pi]: https://github.com/open-telemetry/opentelemetry-python/blob/main/opentelemetry-api/src/opentelemetry/propagators/_envcarrier.py
-
-### Common Behaviors
-
-Both approaches achieve the same outcome while offering different developer
-experiences. Language implementations may choose either approach based on their
-language's idioms and ecosystem conventions. The behaviors in both approaches
-are the same in that they:
-
-1. **Extract context**: Read from environment variables and delegate to the
-   configured `TextMapPropagator` (e.g. W3C, B3) for parsing
-2. **Inject context**: Return a dictionary/map of environment variables that
-   application owners can pass to their process spawning libraries