JOHNZON-398: full JPMS support via module-info.java mechanism

[SingingBush]

This is a follow up to #99 which merely configured Automatic-Module-Name

• Updated a few maven plugins
• Add module-info.java to all sub-projects that makes sense to do so
• Remove Automatic-Module-Name in all sub-projects that now have module-info.java
• Also added a README.md

[rmannibucau]

Overall I'd like to stay in unamed module cause jpms is kind of born dead IMHO and the current pr misses some "static" in requirements making the dep stack no more accurate.
I'd also like to not maintain both mvn and module files but anyway jpms is not a thing and moving out of unamed module breaks apps so not a trivial change until we do it in classified ("jpms") jars IMHO.

[SingingBush]

No problem. May be worth keeping the branch for reference. I'd like to know more about how the intended approach to JPMS would work and can potentially have a go at redoing the PR. I have no legacy projects in my current firm so have been able to make use of modules in all codebases. Personally I find it great and can use the maven jlink plugin to build small apps.

[rmannibucau]

Have to admit we tested jlink and found no advantage over plain custom jvm (but same licenses issues), we tend to move to graalvm for small and optimized apps (with arthur for a trivial jsonb integration) or plain jvm for other oci apps to leverage layer cache so jlink is really something in between without much real use cases IMHO. Most of the use case i saw was perf boost of wrongly configured app (not comparable scanning due to module usage) and adoption stays low in the ecosystem.
That said the breaking change is more an immediate blocker but happy to get classified jar if it helps you.