Clarify the location of tracing's Context interaction.

[carlosalberto]

Clarifies the location of the tracing interaction with Context, i.e. we want to say that this logic can exist anywhere in the API, as long as it exists in a single place.

The mention of a TracingContextUtils class seemed like a too-specific suggestion, hence the removal (in Java we had this class, but ended up putting the Context interaction as static/instance Span directly).

[carlosalberto]

Actually, we may need to also remove the mention of static, as IIRC Ruby poked with the idea of keeping these in the Tracer as instance methods. @open-telemetry/ruby-approvers ? ;)

[Oberon00]

I am against removing "static". I mean I'm open to improving the wording to make it more language neutral, but a Tracer instance MUST NOT be required to interact with the current span. This often leads to misunderstandings, such as that each named tracer manages it's own active span, or complaints such as "why do I need to provide an instrumentation library name to access the current span" (#586).

EDIT: I would be OK with allowing nonstatic methods on the TracerProvider.

[bogdandrutu]

@carlosalberto we can do a separate PR for the "static" if you feel strongly.