Add support for configuration parameters resources

[robinjhector]

Overview

This commit adds support for specifying a properties file, for use with configuration parameters.

• Added a new field configurationParametersResources of type List to store the configuration parameters resources.
• Added new methods configurationParametersResource(String propertiesFile) and configurationParametersResources(List propertiesFiles) to add configuration parameters resources to the request builder.
• Updated the buildLauncherConfigurationParameters() method to include the configurationParametersResources in the Builder instance.

Related to issue: #3340

Open questions:

• The @API annotation values, what should they be? Are they experimental or set to STABLE at once? Which version nr?

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[robinjhector]

Question: I seem to have forgot about the picocli console runner. Should I add new picocli options for selecting a config resource file? (--config-resource perhaps?) in TestDiscoveryOptionsMixin.RuntimeConfigurationOptions

[sbrannen]

Question: I seem to have forgot about the picocli console runner. Should I add new picocli options for selecting a config resource file? (--config-resource perhaps?) in TestDiscoveryOptionsMixin.RuntimeConfigurationOptions

Yes, that sounds like a good idea.

Though maybe --config-resources which accepts a comma-separated list of resource paths.

[sbrannen]

Thanks for submitting the PR.

I requested a few minor changes.

[robinjhector]

Yes, that sounds like a good idea.

Though maybe --config-resources which accepts a comma-separated list of resource paths.

Or just make --config-resource repeatable, like the existing --configcli option? I think I would prefer that, instead of CSVing it.

Also; I couldn't help but notice that the CLI configuration parameters have a strict validation of unique key-value pairs (#1308). And am a bit confused how configuration resources should behave with that in mind.

I would prefer a similar approach as the suite annotations, eg. the explicit parameters take precedence over any property file based ones. Any suggestions or does that sound good?

Edit: Nevermind, I don't think it applies to this anyway. The launcher request builder is used from here, so the logic will be the same regardless.
I've updated the PR with a commit for new CLI options 👍

[robinjhector]

Ping @sbrannen, do you have time to check my fixes to your requested changes?