At least undertow-core becomes a module and is compatible with jlink builds

I often package applications as Java modules with jlink. Recently I came across the difficulties with undertow-core and dependencies upstream. It is not as simple as adding a module-info.java. And it is also not trivial to hack the repositories with jdeps --generate-module-info. Nevertheless I managed to get a minimal project up and running.

Necessary tweaks:

• all logging is completely left aside, no SLF4J, no log4j-api, no jboss-log-manager
• jboss-logging with plain jdeps --generate-module-info, no additional module path
• wildfly-common with jboss-logging in module path
• jboss-threads with jboss-logging and wildfly-common in module path
• wildfly-client-config  with jboss-logging and wildfly-common in module path, dropped schema from JAR, otherwise collides with xnio.api (modules cannot re-define/ enhance/ extend packages)
• xnio-api with all the aforementioned in module-path, added uses org.xnio.XnioProvider; (provides in xnio-nio is not necessary, JDK17 jdeps auto generates correctly)
• xnio-nio with all aforementioned
• undertow-core with all the aforementioned

It'd be much easier if the transitive dependencies would be expressed through requires transitive <module>. But the auto generation process of jdeps cannot be controlled that deep. I also didn't spend the time to sed this in.

The minimal sample uses various request handlers incl. ClassPathResourceHandler (but with SomeProjectClass.class.getClassLoader() instead of system class loader that would not work).

As a user story: As a micro service developer I want undertow-core to become a Java module to be able to package with jlink and fit a full service into a Dockerfile without any base image.