Revisit naming of API and SDK packages

[SergeyKanzhelev]

We discussed naming in #5. We may need to revisit it:

1. Abstraction package have only a subset of classes and interfaces used in SDK. So not really an abstraction. Perhaps rename it to Api instead for consistency with Java?
2. Should we rename OpenTelemetry to OpenTelemetry.Sdk? It will be consistent with Java. But harder for end user to follow the success path of "import OpenTelemetry" and you all set.

Let's discuss naming here

[lmolkova]

I believe keeping Abstractions is pretty consistent with .NET practices (Microsoft ships a lot of packages named like Microsoft.Extensions.Logging.Abstractions or Microsoft.AspNetCorte.Http.Abstractions) and we should keep it here.
I recall OpenCensus had the statement somewhere that typical language practices should be used - can't find it now, do we still prefer it over having the same API everywhere in OpenTelemetry?

[austinlparker]

Idiomatic language practices are good, but what worries me is that we'll end up polluting OpenTelemetry.Abstractions with interfaces that are specific to the reference implementation.

[discostu105]

For me it was a bit confusing at first, not finding the "Api" and "Sdk" layers anywhere. Also "Api" and "Sdk" terms come up in conversations sometimes and it's a bit weird to not have them reflected in the project names.

However, no strong opinion on this. It's good to be idiomatic to a tech.

Concerning "Abstractions": Which interfaces is it supposed to hold exactly?

1. For implementers of "Instrumentations"
2. For implementers of "Tracers"
3. For implementers of "Exporters"

Currently, all the above I would guess. Would it make sense to split out 1. into an "Api" project with minimal API surface?

[SergeyKanzhelev]

I have the same reservations about Abstractions. SDK will have bigger public surface area than API. API package will mostly be for the libraries instrumentation like OpenTracing before