Provide multi-module-aware Run/Debug Configuration with appropriate defaults, and caching of custom-selected values.

There are logically two new fields here (final names TBD):

1. Aggregator (or "top-level", or "root") module home
2. Liberty server module

We map 1. to the working directory and the pom.xml of the invocation, and we map 2. to the -pl <module> value.

DESIGN

• When an aggregate module is selected, it itself should be defaulted as the value of 1. The value of 2. can be blank, which means we will delegate to liberty-maven-plugin to figure out where dev mode should run.

• When a aggregated (sub)module is selected, we use the aggregation model to determine the aggregator module, which we default to be the value of 1., and the value of 2. will be set to the selected module itself.

• Note we do NOT at this point commit to disallowing or filtering out non-server modules, whether because they are JAR packaging types or even WAR packaging types that are not suitable for some reason.

• In Eclipse, we already persist custom values (parms) set on the run configuration. For IDEA and VSCode, we should make sure we do this too.

OTHER NOTES

Note there might also be a need/desire to subclass the Gradle vs. Maven Run config control here, to only show the multi-module components in the Maven one.

Though it could also be desirable to only show this for projects we calculate to be Maven multi-module projects, we might still want to include the fields for ANY Maven multi-module, so that they can reference other projects in the OS filesystem, not just workspace projects.

Start by tracing the Maven Run/Debug Configuration controls and how Eclipse currently persists custom parameters, then compare the IDEA and VSCode configuration paths. Done means the configuration exposes aggregator and Liberty server module values with the stated defaults and persists custom selections across those IDEs.