Update OTel Collector's OpenSearch exporter README.md with clearer guidance on recommended ingestion paths

[horovits]

discussions on OpenSearch community slack workspace's observability channel indicate confusion between using opensearch exporter in the Otel Collector and using Data Prepper, for ingesting OTLP telemetry.
see reference: https://opensearch.slack.com/archives/C052APZA1FA/p1775761863504059
@anirudha suggested taking this task to make the updates following the discussion

[KarstenSchnitter]

I see major short-comings in the current ingestion capabilities of the OpenTelemetry Collector. Some of them are due to the opensearch-exporter plugin and some of them are with the OpenTelemetry Collector itself:

• The OpenTelemetry Collector in general lacks the end-to-end acknowledgements of Data Prepper.
• Failing writes to OpenSearch cannot be redirected easily to other exporters in the collector. I am not sure, if the opensearch-exporter could be extended to support something similar to the dead-letter-queue-pipelines in Data Prepper.
• The OpenTelemetry Collector lacks performance in high-throughput scenarios compared to Data Prepper.
• The OpenTelemetry Collector cannot share state for stateful aggregations. This makes it hard to populate the trace groups required for OpenSearch Dashboards, implement tail-sampling or generate the Service Map.
• Service Map support in OpenSearch Dashboards could be investigated to support the service-map-connector of the OpenTelemetry Collector. But I am not sure it supports the same information.
• The opensearch-exporter does not support the full set of OpenSearch targets: indexes (including write aliases), data streams, ingest pipelines. Therefore it is less versatile.
• OpenSearch might require attribute renaming to avoid field type conflicts. The OpenTelemetry Collector offers little support to implement mitigation strategies. This is a potential extension point for the opensearch-exporter.
• Data Prepper supports ILM policy management for the indexes it writes. It should be investigate to implement something similar within the opensearch-exporter.

I also want to point out, that there is a different option: OpenTelemetry ingest support could be provided directly by an OpenSearch plugin. Here some Data Prepper code could be integrated into the plugin to support an OTLP endpoint within OpenSearch. In that case no special opensearch-exporter would be required in the OpenTelemetry Collector, making the overall setup even easier.