Prometheus -> OTLP: Reconsider server resource attributes from scraped endpoints

[dashpole]

Originally reported here: #4956 (review) by @cyrille-leclerc

The spec currently has:

opentelemetry-specification/specification/compatibility/prometheus_and_openmetrics.md

Lines 393 to 397 in efceef7

	| OTLP Resource Attribute | Description |
	| ----------------------- | ----------- |
	| `server.address` | The `<host>` portion of the target's URL that was scraped |
	| `server.port` | The `<port>` portion of the target's URL that was scraped |
	| `url.scheme` | `http` or `https` |

This adds resource attributes to scraped metrics based on the endpoint they are scraped from. However, metrics themselves may have their own server.address label.

We should consider:

• Migrating to prometheus.server.address, prometheus.server.port, and prometheus.url.scheme. This would prevent collisions, while avoiding breaking users too much.
• Not setting those resource attributes at all. Resource attributes should describe the resource being monitored, not how they are transmitted to the destination. For example, we don't add the OTLP port used when sending OTLP to a collector. Why should scraping be different?

[dashpole]

cc @open-telemetry/prometheus-interoperability

[cyrille-leclerc]

If tracing the origin of telemetry matters for troubleshooting — e.g. distinguishing "emitted by a Prometheus client library scraped from a Prometheus endpoint" from "emitted by an OTel SDK and exported via OTLP" — I think instrumentationScope.name / otel_scope_name and the job resource attribute already cover this, making it unnecessary to capture Prometheus scraping details explicitly.

By the way, I would love in the Prometheus OTLP endpoint to configure the promotion of otel_scope_name (ref Using Prometheus as your OpenTelemetry backend)