Improve integration of build-tools module

[mtf90]

The idea of the build-tools module is to easily reference certain configuration files (e.g. checkstyle config) as maven dependencies (e.g. for plugin executions). While this currently works for 3rd party projects, we cannot use the build-tools module in our own build process.

The reason for this is the introduction of a cyclic reference: The build-tools module depends on the parent module (because it inherits from the parent) and the parent module would depend on the build-tools module if we would declare it as a dependency in the plugin definitions. As a result we currently have to provide the absolute paths to the config files. This breaks the usage of some of the plugins (e.g. we cannot run the findbugs plugin in any module other than the parent, because the configuration paths are always evaluated project-relative, hence it would look in commons/build-utils/... for the configs).

With this ticket I'd like to discuss and evaluate possible solutions to this problem. So far I came up with three ideas:

• do not let build-tools inherit from the parent:
  This way, the build-tools module could be built before the parent and could therefore be referenced by the parent without any problem. The big downside of course is, that all (relevant) configurations currently defined in the parent would have to be copied to the build-tools module, so that it still integrates well in the build process. This would also increase the maintenance burden because all (relevant) configuration changes would need to be applied twice.
• Introduce another build-parent that manages the plugin definitions:
  The new build order would then be:

parent
├── build-tools
└── build-parent
    ├── algorithms
    ├── api
    ├── ...

This would resolve the cyclic dependecy, while still allowing us to configure the build process in a single place. On the other hand this adds another layer of abstraction to the already complex project structure.

• Copy all plugin configurations to the current (relevant) modules:
  In essence, this is the same approach of the second point, but does not introduce a new aggregating module. While this would allow us to keep the project structure as is, it suffers from the same maintenance burden (even more so) as the first point.

From a maintenance point of view, I prefer the second solution the most. Although I don't know how I should feel about this additional layer of abstraction. Any other ideas or feedback on this matter?

Note: The solution of this should also be applied to LearnLib/automatalib, as we have the same problem there.

[mtf90]

I ended up with a small variation of my preferred solution mentioned above.

The main "trick" is, that module defintions (from top to bottom) don't always imply/require a reverse parent declaration (from bottom to top).

This way, the build-parent could simply be defined as a sibling-module, while the other modules may still reference the build-parent as their actual parent. This allows to fix our build-tools integration (single modules can now specify the -Pcode-analysis profile without error 👍) without having to make the project structure more complicated.