Refactor: determine metrics data kind from data_points class instead of instrument_kind

A key challenge in implementing exponential histograms is that the data_points class used to represent them differs from the instrument_kind. Since there is no dedicated API like create_exponential_histogram, exponential histograms are instead created using the generic create_histogram function, followed by applying a view with exponential_histogram aggregation. As a result, both explicit_histogram and exponential_histogram instruments share the same instrument_kind value: histogram.

This creates ambiguity in the current as_otlp_metrics implementation, which must distinguish between explicit and exponential histograms to correctly map to the appropriate protobuf types: HistogramDataPoint or ExponentialHistogramDataPoint.

This issue could become more prominent when users heavily rely on views to modify aggregations.

Additionally, the way otel-python uses the data_points class to encode trace data (as seen in the _encode_metric function) might be better addressed as part of a broader refactoring effort.

Start with the current as_otlp_metrics implementation and compare its handling with the _encode_metric function in the referenced otel-python metrics encoder. Trace how data_points and instrument_kind identify explicit versus exponential histograms, then verify that each maps to the correct protobuf data-point type. Done means the ambiguity is removed and the relevant metrics behavior is covered by existing or updated tests.