Gradle build updates

[jjohannes]

Closes TODO

As discussed @koppor on Slack, here is a proposal to streamline the Gradle build setup and in particular the dependency management setup. This is in preparation to fully use the "Gradlex Module Plugins". But it is also a good improvement in general.

The main change is that the PR introduces a platform/BOM project for all versions versions/build.gradle.kts. This improves two things:

• Control transitive versions: All versions – including transitive versions – are controlled here. I found quite some dependency definitions that were only done to put in a different version (not a dependency). This is conceptually wrong in Gradle - see dependency vs dependency constraint. Also there were a lot of excludes that are not necessary. It's better to avoid excludes wherever possible.
• No version duplication: All versions are now in this one file.

Follow Up

This PR also adds the com.autonomousapps.dependency-analysis plugin. But does not integrate it yet as a permanent check.
A follow up step is to run the plugin – ./gradlew projectHealth – and make all the changes it proposes.

If a dependency is reported unused, you have to check if it is needed at runtime or not:

• Not needed --> remove
• Needed --> change scope to runtimeOnly

Maybe with this you can find some actual unused Jar, before embarking in the quest to do gradlex-org/java-module-packaging#57 (comment)

Steps to test

The JARs that are used in the different places should be the same as before after this change.
Please test whatever you do when developing to verify this.

Mandatory checks

• I own the copyright of the code submitted and I license it under the MIT license
• [/] Change in CHANGELOG.md described in a way that is understandable for the average user (if change is visible to the user)
• [/] Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• [/] Screenshots added in PR description (if change is visible to the user)
• [/] Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• [/] Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[trag-bot]

@trag-bot didn't find any issues in the code! ✅✨

[koppor]

@jjohannes Do you have experiences with maven central publishing - maybe we need some more adjustments as variable names instead of resolved versions seem (!) to get published: #13371