Avoid java.management dependency when JMX is disabled

[vy]

Fixes #2774 by placing code depending on java.management behind a java.management-free check.

[ppkarwasz]

The generated module-info.class still contains the following non optional Java modules:

requires java.base transitive
requires java.compiler transitive
requires java.desktop
requires java.management transitive
requires java.rmi
requires java.xml transitive

We need to mark java.management as static and non-transitive in the BND configuration.

This might cause a couple of problems:

• As far as I know static modules are not loaded by the JVM.They will only be available at runtime if another modules requires them non-"static"ally. If log4j2.jmxDisabled is set to false a JPMS application might still not support JMX. We should test it and document it.
• The AsyncLoggerDisruptor and AsyncLoggerConfigDisruptor classes require RingBufferAdmin. They can fail if java.management is not available.

[ppkarwasz]

I ran a couple of tests on a simple JLink project to find out that:

• the HotSpot JVM always loads java.management if it is present (the module provides an implementation of a LoginModule service that is consumed by java.base), so setting java.management as static should not cause problems to existing users: the module will be present at runtime anyway.
• AsyncLoggerDisruptor and AsyncLoggerConfigDisruptor work correctly even if java.management is missing, so there is nothing to document there.

I think, however, that we should document that setting log4j2.jmxDisabled to false requires JPMS users to add java.management to their module dependencies, otherwise JLink projects will fail to include it.