Jetty 12 - Relax JPMS dependencies

[sbordet]

Jetty version(s)
12+

Description
A few Jetty modules use the clause export ... to ... to export internal classes to other Jetty modules.
For example, jetty-client exports internal classes to Jetty modules that implement specific transports such as jetty-http2-client-transport (and same for fcgi and http3).
Another example is jetty-http2-common exporting internal classes to jetty-http2-client and jetty-http2-server.

This (strict) style has the pro that it does not impact users, who will be able to use the various Jetty client transports without problems, even with JPMS.

However, it has the con that it impacts implementers, those that want to extend Jetty (for example, write a custom HttpClient transport, or write an alternative HTTP/2 implementation that reuses the jetty-http2-common classes).
The impact is that they won't be able to see the internal classes unless they add additional JVM command-line options to export the Jetty internal classes to their own classes.

Given the history of Jetty being a very open project whose component are easily extensible for customizations (even without the Jetty developers being aware of these extensions/customizations), the current JPMS rules should be relaxed.

This will also benefit OSGi, because internal packages are special in OSGi and by default are not exported.
Currently, we have to provide special directives to export those packages in order to have our own HTTP/2 modules work in OSGi.

[sbordet]

What remains to fix are the WebSocket JPMS dependencies, tracked by #9233.