Incremental testing on the CI

I am considering to use GIB https://github.com/vackosar/gitflow-incremental-builder to implement the $subj.

A quick dump of things that are necessary for it to work:

### No "hidden" deps

"Hidden" dependencies of Maven module M are such dependencies, that are required by the module M at build time, but they are not present in the transitive closure of M's dependencies as seen by stock Maven.

The problem occurs e.g. in our integration tests, which explicitly depend only on runtime extension modules, but at build time, they also require their `-deployment` counterparts.

Hidden deps are not a problem for common sequential Maven builds, because the ordering is co-defined by the order of `` elements in the parent-child hierarchy. However, this is an issue for parallel builds using either stock Maven or `mvnd`.

For `mvnd`, we are solving it with `mvnd` specific ``. Clearly, that's not sufficient for GIB, that uses stock maven dependency tree builder. I [learned recently](https://github.com/quarkusio/quarkus/pull/11331#issuecomment-676695992), there is trick how to make hidden dependencies explicit using stock Maven model: one can use a Maven dependency with `pom`, `test` that excludes all its transitives via

```

*
*

```

It is much more XML, but would serve our needs.

Bonus: we will be able to use 'mvn -T1C' both on the CI and locally.

### Check whether GIB handles some corner cases properly:

* Changes of a dependency version in parent (consumed via BoM import) should trigger re-build only of the modules consuming that dependency. GIB will probably not be able to select the optimal set to re-build. If it re-builds all, it is not ideal, but at least, it will not lead to any false positive CI runs.
* Changes of a maven plugin hosted inside the source tree should trigger re-building all modules using the plugin.

Any opnions?

Start by reviewing the Maven parent and module dependency structure, then evaluate GIB against the integration-test deployment dependencies described here. Check whether explicit hidden dependencies support parallel builds and whether changes to imported dependency versions or source-tree Maven plugins select the required modules. Done means incremental CI runs avoid false positives and handle these dependency cases correctly.

Written by the indexing model from the issue text.