Add CI workflow to update intra-repo dependencies to pseudo-version

[jade-guiton-dd]

Context

For some reason which probably has to do with module graph pruning, the go.mod files in contrib sometimes do not mention some of their indirect dependencies. This means no specific version is set for these indirect dependencies.

An example would be the loadbalancingexporter v0.119.0, which requires the otlpexporter v0.119.0 directly, but does not list go.opentelemetry.io/collector in its indirect dependencies, despite it being a direct dependency of the otlpexporter.

This means that the new workflow in collector-contrib which updates its core dependencies to a pseudo-version of the latest main does not (and probably cannot) update all indirect dependencies.

This means that we can end up in the situation where contrib module A requires core module B at v0.119.1-0.2025..., and B requires another core module C at v0.119.0, and there will be nothing in contrib requiring C to upgrade to the pseudo-version as well.

This can cause errors when the main version of a core module is incompatible with the previous released version of another nodule:

• A new package P is added in a core module A, and another module B now depends on it; if B is updated to the latest main but not A, this will cause a module A@latest found (v[last release]), but does not contain package P error, as in this run.
• A package P is removed from core module A, and another module B used to depend on it; if A is updated to the latest main but not B, this will cause a package P provided by A at latest version v[last release] but not at required version v[prerelease], as in this run.
• A package in module A has a breaking change and a package in module B which uses it is updated to match; if A is updated to the latest main but not B, a compilation error can occur because the call site was not updated, as in this run.

A possible solution is to manually update the problematic intra-core dependencies to a pseudo-version, as in #12404, but this is tedious and may have to be repeated multiple times when new errors show up in the update-otel workflow.

(Note that the Go proxy cache makes this even more tedious, as the "latest main" as determined by it can be several hours old.)

Proposed solution

To make dealing with these edge cases either, we should create a new manually-run CI workflow which updates all intra-core dependencies to a pseudo-version of the latest main.

[pratik-mahalle]

Hey @jade-guiton-dd, I would love to implement this