Make OpenTelemetrySdk implement the OpenTelemetry interface and have SPI find it.

[anuraaga]

See #1737 for the discussion.

I don't want to merge a bad PR and a followup renaming like last time since it's confusing and a bit too tedious. I have two commits here, 949bfec is the significant one to check out, the other just applies renames.

Fixes #1109 (each app can have its own OpenTelemetry for different Resource which seems to be the crux of the issue)
Fixes #1149
Fixes #1454
Fixes #747

[anuraaga]

John has suggested using DefaultOpenTelemetry within the SDK, or other, implementations of the API. I think it's a good idea but requires making it public - I'd like to address that in a separate PR.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@23444d6). Click here to learn what that means.
The diff coverage is 77.88%.

@@            Coverage Diff            @@
##             master    #1857   +/-   ##
=========================================
  Coverage          ?   85.56%           
  Complexity        ?     1461           
=========================================
  Files             ?      176           
  Lines             ?     5679           
  Branches          ?      593           
=========================================
  Hits              ?     4859           
  Misses            ?      616           
  Partials          ?      204           

Impacted Files	Coverage Δ	Complexity Δ
...try/exporters/inmemory/InMemoryMetricExporter.java	100.00% <ø> (ø)	8.00 <0.00> (?)
.../main/java/io/opentelemetry/SendTraceToJaeger.java	0.00% <0.00%> (ø)	0.00 <0.00> (?)
...in/java/io/opentelemetry/sdk/OpenTelemetrySdk.java	75.28% <75.28%> (ø)	13.00 <13.00> (?)
...in/java/io/opentelemetry/DefaultOpenTelemetry.java	98.36% <100.00%> (ø)	17.00 <1.00> (?)
.../src/main/java/io/opentelemetry/OpenTelemetry.java	100.00% <100.00%> (ø)	14.00 <2.00> (?)
.../io/opentelemetry/sdk/OpenTelemetrySdkFactory.java	100.00% <100.00%> (ø)	2.00 <2.00> (?)
...n/java/io/opentelemetry/sdk/trace/SpanWrapper.java	100.00% <0.00%> (ø)	22.00% <0.00%> (?%)
...n/java/io/opentelemetry/sdk/trace/StringUtils.java	77.77% <0.00%> (ø)	8.00% <0.00%> (?%)
...in/java/io/opentelemetry/sdk/metrics/MeterSdk.java	100.00% <0.00%> (ø)	18.00% <0.00%> (?%)
...ava/io/opentelemetry/sdk/metrics/ViewRegistry.java	63.63% <0.00%> (ø)	6.00% <0.00%> (?%)
... and 172 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 23444d6...980644f. Read the comment docs.

[Oberon00]

Have you considered #1834? How would we solve this after this PR? (I did not think about it in depth yet -- maybe it gets easier)

[anuraaga]

Added some comments in the issue - I am thinking that regardless we do want to have a single entry point into the SDK. It's the very common use case so presenting the single entry point simplifies the experience. But we may be able to improve the ux for custom sdk users by adding similar entry points into the SDK components. I don't believe that this change would hinder such improvements and want to make those with the understanding that we do want to optimize for the common case of full SDK if we ever make a trade-off.

[jkwatson]

Thanks! This needs a few cleanups, but it's looking pretty solid to me.

[anuraaga]

Reverted QUICKSTART change since we'll do that with the release - copied it to https://gist.github.com/anuraaga/e53f5c226624b6efd83ceb276438ebd4

[jkwatson]

Looks good. Thanks!