[chore] introduce prometheus load test

[bacherfl]

This scenario works a bit differently than the previously added load tests as the prometheus data sender exposes a metrics endpoint from which the collector scrapes the metrics, rather than actively sending the metrics to the collector.

For this reason, the concept using the load generator for the sender had to be changed to instead generate a fixed number of metrics and hand them over to the prometheus data sender (i.e. prometheus server). When using the previous approach the load generator would keep adding metrics that should be served at the prometheus endpoint, which quickly lead to the endpoint becoming unresponsive.
The number of exposed metrics is then read during each scrape iteration of the collector's prometheus receiver, and the overall number of received metrics by the mock backend to which the scraped metrics are forwarded to is increased by the number of exposed metrics after each scrape interval. Therefore it proved best to configure the data items per second via the scrape interval, e.g. With a fixed number of 1000 metrics exposed on the prometheus endpoint, and a scrape interval of 10ms this would relate to a potential throughput of 100k metrics per second.
The bottle neck here seems to be the prometheus servers started by the prometheus data senders, so after decreasing the scrape interval beneath a certain point actually leads to a lower throughput.
With 10 parallel scrape jobs fetching 1000 metrics every second the agent gets killed (e.g. https://github.com/Dynatrace/dynatrace-otel-collector/actions/runs/11026146904/job/30622216193#step:10:272), so I have removed that scenario for now

[bacherfl]

changing the order of the processors, as it is recommended to have the memory limiter before the batch processor: https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/batchprocessor