Set a release manager and schedule based on upstream releases

[rogercoll]

Similar to the upstream strategy: https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/release.md#release-managers

Should @elastic/ingest-otel-data team rotate over the release manager role?

cc @sboomsma

[ChrsMark]

+1 on this!

I think this repository should follow the release schedule of upstream Collector: https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/release.md#10-release

I think of it as an equivalent of the Collector Contrib repository which also consists of standalone OTel components.

Eventually the EDOT Collector should also be updated accordingly to consume the updated Collector Core and if needed newest versions of Contrib's components and Elastic's specific components that the current repo consists of.

Note that EDOT Collector update deps script only updates the upstream deps with https://github.com/elastic/elastic-agent/blob/v9.1.3/.ci/scripts/update-otel.sh. It would be nice to have this one updating the Elastic components too, but for this we would need to follow a unified release process aligned with upstream's versioning.