Streamline the OTLP Metrics export path

[jmacd]

Problem Statement

The OTLP exporters for spans and metrics both perform grouping, both by resource and by instrumentation library, in order to construct the OTLP protocol from a flat listing of spans and metrics. The request in this issue is to streamline the export path so that metrics the same provider are pre-grouped, first by Resource as there is only one allowed according to the Resource SDK specification. Second, metrics aggregations should be pre-grouped according to which Meter produced the span or metric instrument, so it should not be necessary to regroup these data before export.

Proposed Solution

There are two parts:

1. Lift the Resource use for a single provider up to the Export() call, since there can only be one Resource value
2. Pass the Instrumentation Library structure through the metrics pipeline so that Export() requests can be built without re-grouping

Alternatives

Continue re-grouping by resource and instrumentation library in the OTLP metrics path.

Additional Context

Note that tracing does the same form of re-grouping in its export path, but the benefit avoiding grouping is less clear for spans, since spans are not aggregated.

[jmacd]

There is a third part to this issue. The metrics export path for OTLP was performing three grouping steps. (1) by resource, (2) by instrumentation library, (3) by metric name.

#2120 addressed the first.

I have a pending branch to address the second, which will leave one form of grouping in place. This second fix addresses the fact that metric.Descriptor currently contains the instrumentation library name and version--that the current SDK lacks a first-class instrumentation library structure.

Removing the third grouping step will require SDK-only changes and can be deferred.

[MrAlias]

This issues relates to the current metric SDK. The metric SDK redesign project includes changes to the SDK design that will make this issue obsolete. I'm closing so no wasted work is performed to address this.