Possibility to configure project with --add-reads mymodule=ALL-UNNAMED (outside of tests)

*(The following is a part of [bug 526831](https://bugs.eclipse.org/bugs/show_bug.cgi?id=526831) that was not continued. There is a a discussion about it in the [wiki](https://github.com/eclipse-jdt/eclipse.jdt.core/wiki/Java9-ModularityOptions#--add-reads), but most of it is about test code. The wiki page also has the claim "main sources are can do everything in module-info so they are fine.", but this is not correct for `ALL-UNNAMED`. I didn't see any open issue about this so I decided to create one.)*

TL;DR: Please make it possible that Eclipse always adds `--add-reads mymodule=ALL-UNNAMED` to a project's JPMS configuration even *outside* tests.

### More details

I have a partially modularized Java application where its main module depends on stuff on the classpath (for compilation and runtime). I found the build-path setting "Contains test sources" and enabled it for all source folders of the project. Now `--add-reads mymodule=ALL-UNNAMED` is added by Eclipse
- for compilation,
- for running tests, and
- for running the application in debug mode.

However, it is not added when I run a launch configuration of the application outside of debug mode. Then my application fails.

I am aware that I can add `--add-reads mymodule=ALL-UNNAMED` manually to a launch configuration via "Override dependencies" (`MODULE_CLI_OPTIONS`), but this is not a good solution, because I need to do it for every launch configuration and especially new developers (we are open source and have lots of students working on it) will not know that they need to do it nor remember easily what exactly to write.

I also noticed that, if I use the "Add modules" drop-down of the launch configuration and select any of `ALL-DEFAULT`, `ALL-SYSTEM`, `ALL-MODULE-PATH`, Eclipse will not only add `--add-modules` but also `--add-reads mymodule=ALL-UNNAMED` to the command line. But I am unsure whether this is actually intended behavior that I can rely on and whether it has any unwanted side effects. Also, it is still a (not easily discoverable) workaround per launch configuration, so it suffers from the same problems as the manual override.

Thus it would be great if I could configure *in the build path of the project* that my application needs to read `ALL-UNNAMED`. This could for example be done on the "Module Dependencies" tab, which already has the "Read Module..." button that would seem like it does what I need, except that it only offers actual modules and not `ALL-UNNAMED`.

I am using Eclipse 4.35.0 with JDT 3.20.100.

### Background as context for "why would I need this"
I have a larger Java application for which I want to use the JPMS in order to be able to use `sealed` interfaces across packages. The application has too many library dependencies (of which at most very few are modularized or even have a proper module name) and some libraries even do not work easily as a module (example: #2780). So I need to do this stepwise. As a first step, only the application itself is on the module path and all dependencies are on the classpath, and afterwards I will migrate dependencies to the module path step by step. But it will be a long time until the class path is free of non-test dependencies. Alternative suggestions on how to tackle such a migration are also welcome, to me so far this seems like the best plan.

Start with the Module Dependencies tab, its Read Module... control, and launch-configuration handling for MODULE_CLI_OPTIONS. Trace how --add-reads is currently added for test compilation and debug launches, then define project-level configuration that also applies to normal application launches. Done means new launches receive --add-reads mymodule=ALL-UNNAMED without per-launch overrides.

Written by the indexing model from the issue text.