Associate views with MeterProvider instead of Reader

[MrAlias]

Resolve #3241
Resolve #3210
Resolve #3085

Follow the v1.14.0 version of the metric SDK specification and register views with a MeterProvider instead of with a Reader.

This change naturally includes a resolution to #3085 as there is no longer a need to map readers to views.

[codecov]

Codecov Report

Merging #3387 (d30ca62) into main (c8a13d6) will decrease coverage by 0.0%.
The diff coverage is 84.6%.

❗ Current head d30ca62 differs from pull request most recent head 0692303. Consider uploading reports for the commit 0692303 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3387     +/-   ##
=======================================
- Coverage   77.9%   77.9%   -0.1%     
=======================================
  Files        164     164             
  Lines      11361   11366      +5     
=======================================
- Hits        8861    8859      -2     
- Misses      2301    2307      +6     
- Partials     199     200      +1     

Impacted Files	Coverage Δ
sdk/metric/config.go	94.3% <77.7%> (-5.7%)	⬇️
sdk/metric/pipeline.go	93.4% <100.0%> (ø)
sdk/metric/provider.go	100.0% <100.0%> (ø)
sdk/trace/batch_span_processor.go	80.2% <0.0%> (-1.8%)	⬇️
codes/codes.go	90.4% <0.0%> (ø)

[MadVikingGod]

When it was last discussed, we took a views-per-reader approach specifically to support the use case: High-frequency export of a subset of metrics, and a low-frequency export of a full set. E.g. every 10 seconds get status + response counts, and for every minute get the histogram of response times + everything else.

It doesn't look like we can support this use case with this approach.

That being said, we are the only project that does this.

[MrAlias]

That being said, we are the only project that does this.

I think this is the key. If the OTel community decides to add support for this in the future we can definitely add it back. 👍