Feature: Better config modularity & alignment to nf-core config

[JosuaCarl]

Related Issues

• Files are currently only given with {traceFile: path/to/file.txt}, whereas nf-core uses {trace: [file: path/to/file.txt]}

🎯 Motivation

• Align plugin config with nf-core template
• Improve modularity and checking during config creation and calling

📋 Summary of changes

• Added BaseConfig class for configurations to make repetitive calls upon methods in a config easier
• Added ConfigEntry to define entries of our config with desired attributes, including dynamic default initialization, type checking on every value change, nested Configurations setting, initialization indication
• Added config classes for base file type and each specific file
• Removed CO2Footprint from naming of nested classes, to avoid redundancy and long names

📌 Important details

• Left originally configurable file parameters (overwrite & maxTasks) configurable for the respective files

✅ Checklist

• New functionalities are covered by tests
• Class structure in test reflects class structure in main
• Documentation reflects changed behaviour
• README.md contains information on or reference to new features
• CHANGELOG.md is updated with a note on your changes
• Ensure all tests pass (.\gradlew check)

[nadnein]

Comments I have so far, I will continue tomorrow, it's a loooot :D

[nadnein]

Suggested change

	Double getCi() { evaluate('ci') }
	Double getCiMarket() { evaluate('ciMarket') }
	/**
	* Returns the carbon intensity value.
	* If set as a closure (for real-time API), invokes it to get the current value.
	*/
	Double getCi() { evaluate('ci') }
	/**
	* Returns the personal energy mix carbon intensity value.
	* If set as a closure (in case user defined a function for it in the config), invokes it to get the current value.
	*/
	Double getCiMarket() { evaluate('ciMarket') }

[JosuaCarl]

I intentionally deleted the comments, because the functionality should be clear form the commented evaluate function. I would rather modify this and keep the flow of the getmethods.

[nadnein]

Why are those functions needed?

[JosuaCarl]

toString is mostly for debugging. The debugger calls the method to describe the instance. I found it really helpful and would definitely keep this.
toMap was intended for easier testing. Although I think I did not end up using it. But then again, I could also expand on the test of the class.

[nadnein]

Hmmm shouldn't variable names be as descriptive as possible and not have vague names? And storage or vault is super generic and not descriptive for that variable