feat(api): propagate spanContext only using API #1456

[vmarchaud]

This one is a little bit tricky, since it was assume from the start that the API could only contains noop we put the context management utils into the core.

As you can see in this PR, we need to get the spanContext stored inside the context from the Noop implementation, there are two way do to this:
- duplicating the declaration of the key, one in the API's noop tracer and one inside the core for general usage.
- moving the key declaration inside the API, but while at it why not move them all ? Specially since they all use API interfaces.

Waiting for feedback before marking as non-draft !

Fixes #1456

[codecov]

Codecov Report

Merging #1527 into master will decrease coverage by 0.47%.
The diff coverage is 97.22%.

@@            Coverage Diff             @@
##           master    #1527      +/-   ##
==========================================
- Coverage   93.43%   92.95%   -0.48%     
==========================================
  Files          98      144      +46     
  Lines        3518     4332     +814     
  Branches      768      871     +103     
==========================================
+ Hits         3287     4027     +740     
- Misses        231      305      +74     

Impacted Files	Coverage Δ
...y-core/src/context/propagation/HttpTraceContext.ts	100.00% <ø> (ø)
packages/opentelemetry-tracing/src/Tracer.ts	98.33% <83.33%> (ø)
packages/opentelemetry-api/src/context/context.ts	83.33% <100.00%> (ø)
packages/opentelemetry-api/src/trace/NoopTracer.ts	100.00% <100.00%> (ø)
...metry-core/src/context/propagation/B3Propagator.ts	100.00% <100.00%> (ø)
packages/opentelemetry-plugin-http/src/http.ts	97.81% <100.00%> (ø)
...ackages/opentelemetry-shim-opentracing/src/shim.ts	87.70% <100.00%> (ø)
...telemetry-tracing/src/export/BatchSpanProcessor.ts	91.93% <100.00%> (ø)
...elemetry-tracing/src/export/SimpleSpanProcessor.ts	83.33% <100.00%> (ø)
... and 75 more

[Flarna]

I think the key shouldn't be duplicated. Having details like this in core results in further problems like various plugins depend on core.
As a result it's not possible to implement our own SDK but reuse plugins.
If the API is the entrypoint for plugins it should contain everything needed by them.

[dyladan]

I was the one that originally put those context management functions in the SDK instead of API. The reason for this at the time was that I was thinking they were sdk-specific implementation details, but it has become clear since then that the API is not really that useful without them. I think they can be moved into the API.

[vmarchaud]

I will update the PR to move them into the API then 👍

[vmarchaud]

I've rebased the PR

[mwear]

LGTM