MetricReader redesign

[cijothomas]

MetricReader is an important aspect of the OTel Metric Specification. It is currently part of the public API in OTel Rust, though it is rarely required by end users to directly deal with MetricReaders. (100% of examples in the repo - no need of learning about MetricReader at all, as it is handled transparently)

The design of MetricReader has some challenges, especially in locking the Public API. Opening an issue to track improvements to the same.
Few items from top of mind:

1. Consult OTel TC/GC to get an exemption from having to build Prometheus Exporter in this repo. While we already deprioritized it, we need an official blessing to remove it completely. The "pull" model used by Prometheus has some design challenges, and if we can avoid that, it'll make MetricReader design a lot more simple.
2. See if there is any issue marking MetricReader under an experimental feature, allowing us to make breaking changes to it in the future. If this is feasible, this can unblock the stable release of Metrics Sdk.
3. See if it is possible to mark 2 methods in MetricReader trait as experimental. (Collect, register_pipeline are the ones questionable.) This is a smaller version of 2 from above.

I don't expect any disruption to end-users as they don't really have a need to deal with MetricReader. Ability to write custom MetricExporters will be continued as is.

cc: @fraillt

[fraillt]

I would also like to emphasize that, with the current MetricReader design, we're not able to make certain changes to PushMetricExporter (e.g., adding set_resource(&mut self, ...)), which would help make all exporters more consistent.

[cijothomas]

Questionable APIs are now moved to experimental_feature flags, and that is the extent of what we plan for the coming release.