Merge all Jenkinss job associcated to a full I-build into one large Jenkins pipeline

[HannesWell]

At the moment the a full I-build is composed of the following Jenkins jobs (If I haven't missed one):

1. https://ci.eclipse.org/releng/job/Builds/job/I-build-4.32/
2. I-build test execution
   • https://ci.eclipse.org/releng/job/AutomatedTests/job/ep432I-unit-cen64-gtk3-java17/
   • https://ci.eclipse.org/releng/job/AutomatedTests/job/ep432I-unit-cen64-gtk3-java21/
   • https://ci.eclipse.org/releng/job/AutomatedTests/job/ep432I-unit-mac64-java17/
   • https://ci.eclipse.org/releng/job/AutomatedTests/job/ep432I-unit-macM1-java17/
   • https://ci.eclipse.org/releng/job/AutomatedTests/job/ep432I-unit-win32-java17/
3. https://ci.eclipse.org/releng/job/Releng/job/ep-collectResults/
4. https://ci.eclipse.org/releng/job/Releng/job/updateIndex/ (also used by Collect Y-build Results and Make Visible

These distributed Jobs make it relatively hard to understand how an I-build works in detail and therefore to maintain it, even tough they created by a seed-job, who's definition is maintained in this repository.

Implementing the I-build procedure into one large Jenkins pipeline would probably make it simpler. Using the same approach as in SWT, we can easily run some parts of the pipeline on other agents (i.e. the I-build tests that should run special platform-specific agents).

There are probably many details to consider but in general I think it should be doable and beneficial. What's your opinion? Do think that would be beneficial? Do you see any blockers?

[akurtakov]

There are way too many jenkins jobs and not many(if anyone!) that knows them all so any reduction in their number should bring some sanity and make it possible to see the order of things and relateions better.