Refactor the SDK helpers, create MeterImpl

[jmacd]

This reduces the boilerplate needed to implement the Meter. api/metric/sdkhelpers.go now defines a 4-method MeterImpl interface which supports general-purpose constructors instead of specific ones, i.e., NewSynchronousInstrument and NewAsynchronousInstrument. The two implementations (the Mock and the real SDK) are simplified. The global Meter implementation is also refactored to share as much of possible of this code, however it is written not to require the use of MeterImpl, as it is just a helper. (An SDK could decide to implement the constructors directly.)

This refactoring is a precursor to #514, since after we have the four-method MeterImpl a name-uniqueness wrapper will simply wrap around the MeterImpl and provide uniqueness checking.

Removes the Unregister() method for observers, since it was not in the spec. This can be restored in another PR if needed, but I would prefer we ask users to shut down the SDK instead of unregistering observers.

[jmacd]

Reviewers: see how I intend to build off of this functionality in #566

[krnowak]

Did a quick review, will need to make it more thorough tomorrow. But overall looks good. It certainly brings some nice simplifications and reduces the repetitive code.

[MrAlias]

I need to dig deeper into this, but wanted to provide my initial feedback. It is mostly small naming/docs questions. But, one overall thing I'm wondering is if it was considered to use Async*/Sync* instead of Asynchronous*/Synchronous*>

[jmacd]

I want to add that this PR is far from perfect. One of the decisions that I had trouble making was whether the new wrappedMeterImpl in sdkhelpers.go would be used as merely a convenience or whether all SDKs would be required to use it. It seemed like taking a step too far to require SDKs to implement the MeterImpl generic constructors (i.e., NewSynchronousInstrument and NewAsynchronousInstrument) since it could conceivably force them to create generic code they otherwise would not have to / want to.

This matters for the code in api/global, which would be a bit simpler if it could assume that any Meter set as the global instance had an underlying MeterImpl. This only matters a little bit, however, since the API forces the SDK to provide a SynchronousImpl or AsynchronousImpl for each instrument constructed.

As it stands, therefore, the code in api/global is not written to assume that the global instance it deals with can be unwrapped. For the global package and any SDK that doesn't want to implement MeterImpl, sdkhelpers.go also provides the Wrap*Instrument helpers.

This means that the code in #566 doesn't tell the whole story. The real SDK can acquire uniqueness checking by being wrapped in a new MeterImpl as shown in that PR, but the global package has to expand the access checks into each constructor by hand. So part of me wonders how it would look if: (1) all SDKs were required to implement MeterImpl, and (2) the global package was implemented using a wrapped MeterImpl instead of a custom implementation as it stands here. This might make uniqueness checking nice, but I'm not sure it will improve readability in the globals package, which is quite complicated.

[jmacd]

I added some detail in #566. I now think it won't actually help to assume that all Meter implementations are wrapped MeterImpls. I've put some notes into the api/global/internal package where the changes would go, and I think I'm happy with this change (although the PR is too large, sigh).

[MrAlias]

I think this is at a place it should be merged.

That said it does look like there can be some subsequent cleanup, like you mentioned. In particular, I think the sdkhelpers.go file could use being split up and probably some more documentation, but looks good for a first iteration.

The only real concern I've included in the GetDescriptor method on the SDK. It seems like something we should decide on removing/keeping sooner rather than later.

Overall, excellent work. I think this paired with what it enables in the uniqueness checking to follow it is a step in the correct direction.

[jmacd]

I added a Synchronous->Sync and Asynchronous->Async change. I generally agree, @MrAlias, that a bunch of cleanups and moving things into different files would help. I tried to keep things in place to help the diff be readable. I'd be all for a change that only moves things around for clarity without any functional changes.

[krnowak]

Looks good. All I found were documentation nits.

[rghetia]

Nice work!
One minor non-blocking comment.