Inconsistent API design between trace and metri

[bogdandrutu]

Currently the trace API is design using interfaces without any implementation detail, but the metric is design more like a "driver" pattern.

I would suggest that we pick one design model and implement that consistently between trace and metric APIs.

[jmacd]

I'm open to what others think about this, but I feel the trace and metric interfaces are substantially different beasts, and the distinctions here are appropriate. Every metric API boils down to an event with one number and some labels and a descriptor that says what it means. Forcing an SDK to implement 6 interfaces w/ 3 methods each is a burden for no benefit that I can see.

Since I created this structure, it should be up to others to comment. One comment that I remember from the past was this, #100 (comment), wherein @cep21 remarked that there were too many methods in the interface. I'm sure the addition of 6 new constructors is a bit smelly too, but those aren't the methods we're talking about. The current design lets an SDK implement one method for new handles and one method for direct calls, which I think is pretty convenient. Moreover, if we removed core.Number from the API, then every SDK would be forced to reinvent such a mechanism.