chore: use interface for context types

[dyladan]

In most cases, our current code base is using the concrete Context class as a type. This makes for incompatibilities when differing versions or subclasses of elements using context are used. For instance, it is possible to create a TracerProvider which satisfies all of the public methods, but typescript complains when you try to register it with the global API because private methods mismatch, even though they aren't used by the API.

This changes the context-base module to export an interface, and root context which is declared to have the type of the interface, not the concrete class. This also changes usages of Context throughout the project to use the interface and the new exported root context.

Overall, this enhances the separation of the API module and its interfaces from the concrete implementations of the SDK and context.

[codecov]

Codecov Report

Merging #1515 into master will decrease coverage by 0.00%.
The diff coverage is 88.88%.

@@            Coverage Diff             @@
##           master    #1515      +/-   ##
==========================================
- Coverage   93.82%   93.82%   -0.01%     
==========================================
  Files         154      154              
  Lines        4763     4761       -2     
  Branches      952      952              
==========================================
- Hits         4469     4467       -2     
  Misses        294      294              

Impacted Files	Coverage Δ
packages/opentelemetry-api/src/api/propagation.ts	57.57% <0.00%> (ø)
...ackages/opentelemetry-shim-opentracing/src/shim.ts	88.00% <ø> (ø)
...ry-context-zone-peer-dep/src/ZoneContextManager.ts	85.18% <75.00%> (-0.19%)	⬇️
packages/opentelemetry-context-base/src/context.ts	76.47% <85.71%> (-1.31%)	⬇️
...ontext-async-hooks/src/AsyncHooksContextManager.ts	100.00% <100.00%> (ø)
...async-hooks/src/AsyncLocalStorageContextManager.ts	100.00% <100.00%> (ø)
...entelemetry-context-base/src/NoopContextManager.ts	100.00% <100.00%> (ø)
packages/opentelemetry-core/src/context/context.ts	95.83% <100.00%> (ø)
...metry-core/src/context/propagation/B3Propagator.ts	100.00% <100.00%> (ø)
...ore/src/correlation-context/correlation-context.ts	100.00% <100.00%> (ø)
... and 1 more

[dyladan]

@xirzec we recently had a brief conversation about the idea that concrete classes have discrepancies more often than interfaces. Curious to know what you think of this change since my intention is to alleviate issues similar to what we discussed then.

[xirzec]

@dyladan Yes, the issue you're solving with this PR is the exact reason I've started preferring interfaces whenever possible. Nice work!

[dyladan]

@open-telemetry/javascript-approvers would like to get this merged before I leave for vacation :)

[dyladan]

@dyladan Yes, the issue you're solving with this PR is the exact reason I've started preferring interfaces whenever possible. Nice work!

OK good. Just wanted to make sure I understood fully the issue you were trying to solve. I believe we will also have the same problem with TraceFlags, which is currently an enum in the API. Aside from the fact that enum is an incorrect type for this, it also causes typescript to fail if you bring your own tracer which redefines this enum.

[obecny]

lgtm, one concern with keeping the static

[dyladan]

@obecny fixed PTAL

[obecny]

lgtm