Add module_template_rollout job in workflow

[Subramanian-K812]

A new job module_template_rollout has been added to _local_daily.yml.

What the job does

Runs daily (and on manual trigger). For each eclipse-score repo that has a
.bazelversion file:

1. Reads the current .bazelversion from eclipse-score/module_template
2. Compares it against each repo's version
3. If outdated: creates a branch, commits the updated version, opens a PR

Testing

Tested manually using workflow_dispatch with target_repo input, targeting
qorix-group/reference_integration (.bazelversion = 8.4.2).

The job correctly detected the gap vs template (8.6.0) and opened a PR:
→ qorix-group/reference_integration#16

[FScholPer]

We should not build workflows for single update sync. I would propose to utilize a single workflow for template sync like the one I created some time ago:https://github.com/eclipse-score/cicd-workflows/blob/main/.github/workflows/template-sync.yml. @AlexanderLanin any thoughts on this?

[AlexanderLanin]

@FScholPer thats kind of exactly the point on how to roll this out. It seems we have some options, and either we make a full fledged DR or we discuss it next Monday in infrastructure meeting?!

My current thought process:

• we can put it into the template, and "all repos" therefore get it once somehow. Then they do self update. We end up maintaining 20+ self update workflows.
• to make life easier for infrastructure team a push approach (like renovate) is easier, as all config is in a single place.
• but then it doesn't belong into the module_template repository, as we dont want modules to have copies of that workflow. It shall be in a single place.
• therefore cicd-workflows, as thats the best matching such place

[AlexanderLanin]

Is ahmadnassri/action-template-repository-sync a viable + good option for this workflow? (Just asking, not suggesting)

Update: no, it relies on proper template usage. Half our modules use the template without "using" it.

[AlexanderLanin]

Review:

• this PR solves the problem statement perfectly.
• Will probably require slight fiddling to pass ECA check
• We need prettier PR descriptions ;-)

Open points to discuss:

• General approach (workflow in this repo?)
• Generic approach (solve current problem vs solve all sync problems)

[AlexanderLanin]

Gap: if some repository rejects the PR, they should not get the same one on the next day.