Prometheus metrics are merged when they differ by trimmable suffixes

[dashpole]

Describe the bug
The prometheus receiver is renaming metrics if they differ from another metric by a trimmable suffix, and associating them with the wrong metric metadata.

Steps to reproduce

With the metrics:

# HELP my_metric_total A counter metric
# TYPE my_metric_total counter
my_metric_total 0.5
# HELP my_metric A gauge metric
# TYPE my_metric gauge
my_metric 2

The my_metric_total metric is renamed to my_metric, and the gauge metadata is used. This is because with the current logic, we checked for a trimmed metric name before we check for the untrimmed metric name. So if a metric exists with the metadata for my_metric, the my_metric_total metric will use that if it exists.

This results in a single metric named my_metric, which is a gauge, and has values 0.5 and 2.

What did you expect to see?

I expect to see both the my_metric and my_metric_total with correct metadata, and correct values.

What version did you use?
Version: HEAD

Additional context

In #4865, we handled the case in which the metric python_gc_objects_collected_total had metadata under python_gc_objects_collected, which was supposed to be how the python client wrote counter metrics.

However, after experimenting with the python client, I found that to be incorrect:

# HELP python_gc_objects_collected_total Objects collected during gc
# TYPE python_gc_objects_collected_total counter
python_gc_objects_collected_total{generation="0"} 167.0
python_gc_objects_collected_total{generation="1"} 174.0
python_gc_objects_collected_total{generation="2"} 0.0

Python does attach _total to the metric, but it does not send metadata without the _total suffix. There is a test case that tests for that, and should be removed or reworked.

[dashpole]

cc @gracewehner @Aneurysm9