Update/fix release process and docs

[ChrsMark]

We should update

opentelemetry-collector-components/docs/release.md

Line 1 in e7ef735

# Releasing opentelemetry-collector-components

so as that it can be followed for the update/release process.

Ideally, we should use https://github.com/elastic/opentelemetry-collector-components/blob/main/versions.yaml as the source of truth going forward following a unified release versioning for our components.

/cc @sboomsma @rogercoll

[ChrsMark]

@axw would that be an issue for mOTEL team(s) if versioning and releasing will follow the frequency of upstream Collector's releases?

I see for example that https://github.com/elastic/opentelemetry-collector-components/releases/tag/processor%2Fratelimitprocessor%2Fv0.9.0 was released today with a new feature in. Would that be viable to wait 2 weeks until the next upstream release will trigger our internal upgrade/release process?

This will allow us to use https://github.com/elastic/opentelemetry-collector-components/blob/main/versions.yaml and the make push-tags target to horizontally tag and then release the components following a single versioning which will also be aligned with upstream Collector.

If that's not possible I see 2 options here:

1. create an extra different MODSET in https://github.com/elastic/opentelemetry-collector-components/blob/main/versions.yaml to group the components needed more frequent releases. Then handle the 2 groups independently where the edot-base one will only be used bi-weekly after upstream releases and the one needed for mOTEL will be used at-will but also right after the upstream release.
2. create a new script which will just bump up all needed components from where they are (example PoC: Add releaser script and tune docs #818)

Additionally, we also need to decide if we want to publish single repo-scope tag and release after the multimod tags or if we should continue with releasing per component.

I think that if we go need to have divergent release frequency for the components then option 2 is our best bet.
@rogercoll I'd love your thoughts here too.

[axw]

@ChrsMark I think it's OK since we can always pin to commits in between. @vigneshshanmugam WDYT?

[vigneshshanmugam]

++ agreed with you on pinning the commits.

The challenge comes in when we’re updating the upstream otel/* component versions in tandem with these components. As long as we can stay aligned with the upstream release cadence, we should be in a good IMO.

[ChrsMark]

Thank's for the feedback @vigneshshanmugam @axw! After discussions, the current suggestion is to have a common horizontal version for all of the components but not couple it with upstream Collector's version. This means we will be able to cut new releases at will by bumping up all the components horizontally using the make push-tags. I will send a PR for this.

[ChrsMark]

PR is up: #826

@vigneshshanmugam @axw @rogercoll feel free to take a look