Code Infrastructure: create a Maven Parent POM and integrate existing

[poikilotherm]

This is influenced by #7662 / #8320 , #8383, #6505 / #6986, #8250, #2331 and related.

Tagging @qqmyers @landreev @scolapasta @pdurbin here.
EDIT: @pdurbin suggested this is related to #2331 and @donsizemore suggested this might be related to activities by @akio-sone

Current status

• Currently, there is a standalone pom.xml to compile, test and package the Dataverse WAR.
• The ZIP downloader JAR also has a standalone pom.xml in subdir scripts/zipdownload

Envisioned future

• Create a parent POM in a subdirectory of project root (e.g. conf/pom.xml or a new folder structure modules/dataverse-parent/pom.xml or similar).
• Inherit in edu.harvard.iq.dataverse POM from parent
• Move relevant sections and parts from <properties>, <pluginRepositories>, <repositories>, <dependencyManagement> and maybe some of <build> into the parent POM
• Make ZIP downloader POM inherit from parent

Possibilities

• Enable consistent dependency management for main project and ZIP downloader
• Enable central configuration of Maven metadata, repositories etc (also needed to upload to Maven Central one day)
• Enable dependencies between our modules
• Enable starting to transform the main codebase from a monolith to a modulith, enabling reuse of code parts like storage access (looking at you, ZIP downloader)
• Decouple main development POM maintenance from other activities like Maven based containers (but still be able to depend on them!)
• Future replacement of scripts/installer/Makefile with a Maven submodule dataverse-release doing the packaging? Maybe also doing the actual release process (JReleaser FTW!)?
• Future release dataverse-parent on its own, enabling other projects to inherit.

Hints

• @pdurbin suggested to give an example of a not-to-complex project using Maven modules. Here is a very similar one to Dataverse 😋 : https://github.com/DSpace/DSpace (Although they aren't having a parent in a subdirectory - this is sth we need to be backward compatible for at least some time)
• The current pom.xml will not be moved, just transformed. No Git history "lost"/"invisible". Any developer currently acclimated with using mvn <target> to interact with the main codebase on project basedir will not need to change habits. Obviously shared properties etc would be managed within the parent.
• The parent POM is not only usable for inheritance, but also for aggregation. Accessing the subdirectory and running a Maven target will include all submodules in one go, respecting dependencies.
• For easier insights into my suggestion, I created a working pull request: 8394 maven mods #8395 Feel free to add any suggestions etc.