Align view configuration with specification

[MrAlias]

Currently, the specification defines view configuration to be associated with a MeterProvider:

The SDK MUST provide the means to register Views with a MeterProvider

Furthermore, it implies this registration is a one-to-one mapping between views and MeterProvider:

If the MeterProvider has one or more View(s) registered

Our current implementation registers views in conjunction with a Reader. There is a one-to-one mapping of views to Reader. There can be multiple of these pairs registered with a MeterProvider.

This issue is to serve as block to releasing the metric SDK as stable until the specification is updated (see open-telemetry/opentelemetry-specification#2288) or we change how we register views.

[MrAlias]

The current proposal in #3210 is to move the view registration into the Reader directly. If the resolution to this issue to modify the specification, that modification should take that approach into consideration.

[MadVikingGod]

This was decided to take this form for two reasons:

1. This allows for independent views per reader. They can be reused, because they don't have state, but if I need to rename something when exporting to prometheus but not to otlp that is possible in this configuration.
2. We don't control the constructor for ALL Readers, just ManualReader, PeriodicReader, and now Prometheus. We can't enforce that Readers will take views into account.

We do comply with the wording of the spec, Views are "registered" with a MeterProvider via only an Option, something the MeterProvider takes and uses.

Furthermore, this was the intent of views, as expressed in spec meetings on this subject.

[MrAlias]

Furthermore, this was the intent of views, as expressed in spec meetings on this subject.

This sounds good 👍, we just need to ensure the specification is updated to reflect this intention before we can release a stable package.

[MrAlias]

It doesn't seem like open-telemetry/opentelemetry-specification#2288 is going to be resolved any time soon.

I think we need to move this issue to Todo and work to refactor our implantation to conform with the specification so we do not block our v1 release.