Make JPMS parameters work with and without enabling Jetty JPMS mode

This is a two split issue from end user perspective. Some need to be fixed in the docker image and some in jetty itself. The main goal is to make JPMS useable.

Consider a web application that has some old libraries (before JPMS) and newer ones that may or may not have JPMS metadata. Yet the application needs some `--add-opens` parameter to make some libraries work properly.

Migrating to the official jetty docker image has the following issues:
1. Nearly every java based docker image has a `JAVA_OPTIONS` env variable that is passed to the final JVM being executed in the container as is. A Dockerfile like
```dockerfile
FROM jetty:10.0.15-jdk17-eclipse-temurin
ENV JAVA_OPTIONS --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED \
--add-opens java.base/sun.nio.ch=ALL-UNNAMED \
--add-opens java.base/jdk.internal.misc=ALL-UNNAMED \
--add-opens java.base/java.nio=ALL-UNNAMED \
-Dio.grpc.netty.shaded.io.netty.tryReflectionSetAccessible=true
```
should just work without issues. However the above results in a `jetty.start` file that contains (spaces replaced with newline for readability)
```
exec
/opt/java/openjdk/bin/java
-Djetty.home=/usr/local/jetty
-Djetty.base=/var/lib/jetty
--add-opens
-Dio.grpc.netty.shaded.io.netty.tryReflectionSetAccessible=true
--class-path
```
This command is broken because the single `--add-opens` does not have a parameter value and the remaining `--add-opens` are swallowed completely.

2. Using a custom jetty module to use JPMS as envisioned by jetty would look like
```
[description]
App JVM Parameter

[tags]
jvm

[ini]
--jpms

[exec]
-Dio.grpc.netty.shaded.io.netty.tryReflectionSetAccessible=true

[jpms]
add-opens: jdk.management/com.sun.management.internal=ALL-UNNAMED
add-opens: java.base/sun.nio.ch=ALL-UNNAMED
add-opens: java.base/jdk.internal.misc=ALL-UNNAMED
add-opens: java.base/java.nio=ALL-UNNAMED
```
However after activating such a module the `--dry-run` command emits a command line that contains `--module org.eclipse.jetty.xml/org.eclipse.jetty.xml.XmlConfiguration `. The `generate-jetty-start.sh` script executes a regex on the `--dry-run` output and that regex filters the emitted command line resulting in `jetty.start` being empty and the container fails to start. The regex always searches for `org.eclipse.jetty.xml.XmlConfiguration` surrounded by a single space character which is not given in JPMS mode. See regex at: https://github.com/eclipse/jetty.docker/blob/992eabbc38b2694207852286b15623dc18e67978/eclipse-temurin/10.0/jdk17/generate-jetty-start.sh#L8C3-L10C56

3. In my opinion a custom jetty module should also allow defining JPMS parameters in the `[exec]` block because there are situations you do not want to fully enable JPMS by using module-path but still want to open some packages for reflection. This could be done using `JAVA_OPTIONS` if 1. is fixed but I think it is still valid to have a custom module that should work the same.
```
[exec]
--add-opens
jdk.management/com.sun.management.internal=ALL-UNNAMED
--add-opens
java.base/sun.nio.ch=ALL-UNNAMED
--add-opens
java.base/jdk.internal.misc=ALL-UNNAMED
--add-opens
java.base/java.nio=ALL-UNNAMED
-Dio.grpc.netty.shaded.io.netty.tryReflectionSetAccessible=true
```
However the above fails because all `--add-opens` parameters will be deduplicated resulting in a broken command line again (spaces replaced with newline for readability):
```
exec
/opt/java/openjdk/bin/java
-Djetty.home=/usr/local/jetty
-Djetty.base=/var/lib/jetty
--add-opens
jdk.management/com.sun.management.internal=ALL-UNNAMED
java.base/sun.nio.ch=ALL-UNNAMED
java.base/jdk.internal.misc=ALL-UNNAMED
java.base/java.nio=ALL-UNNAMED
-Dio.grpc.netty.shaded.io.netty.tryReflectionSetAccessible=true
--class-path
```
This is also tracked in https://github.com/eclipse/jetty.project/issues/8348 and there was a workaround for it before jetty introduced quotes on parameters. Now with quotes this workaround does not work anymore. I repeated that issue here to have a full view of the usability problems.