Update case folder structure and examples

[lbonaldo]

Description

This PR updates the folder structure of a GenX case, and selects the examples for v0.4.
The proposed version is the following:

example_case
│ 
├── settings
│   ├── genx_settings.yml
│   ├── [other solver settings]
│   └── highs_settings.yml
│ 
├── system
│   ├── Demand_data.csv
│   ├── Fuel_data.csv
│   ├── Generators_variability.csv
│   ├── Operational_reserves.csv
│   └── Network.csv
│ 
├── policies
│   ├── CO2_cap.csv
│   ├── Minimum_capacity_requirement.csv
│   └── Energy_share_requirement.csv
│ 
├── resources
│   ├── Thermal.csv
│   ├── Storage.csv
│   ├── Vre.csv
│   ├── Hydro.csv
│   └── policy_assignments
|       ├── Resource_minimum_capacity_requirement.csv
│       └── Resource_energy_share_requirement.csv
│ 
├── TDR_results
├── results
├── README.md
└── Run.jl

Tests and examples have been updated to match the new folder structure, and the naming convention for folders is snake_case, to match the rest the of the source code.

All the current examples can be moved to a separate repository together with the new tutorials: https://github.com/GenXProject/GenX-Tutorials

Please feel free to add any comments or suggestions you may have on this PR.

What type of PR is this? (check all applicable)

• Feature

Checklist

• Code changes are sufficiently documented; i.e. new functions contain docstrings and .md files under /docs/src have been updated if necessary.
• The latest changes on the target branch have been incorporated, so that any conflicts are taken care of before merging. This can be accomplished either by merging in the target branch (e.g. 'git merge develop') or by rebasing on top of the target branch (e.g. 'git rebase develop'). Please do not hesitate to reach out to the GenX development team if you need help with this.
• Code has been tested to ensure all functionality works as intended.
• CHANGELOG.md has been updated (if this is a 'notable' change).
• I consent to the release of this PR's code under the GNU General Public license.

How this can be tested

I ran all the example cases and the tests that are available.

Post-approval checklist for GenX core developers

After the PR is approved

• Check that the latest changes on the target branch are incorporated, either via merge or rebase
• Remember to squash and merge if incorporating into develop

[cfe316]

It makes me a bit nervous that policy files are being joined one-to-one with policy settings. While right now this is the case, it doesn't seem like a fundamental thing. What if some new policy requires two files?

[cfe316]

Consider making these five lines to construct my_dir be a function (of setup, data_directory, and path I suppose) since they're repeated in load_demand_data, load_fuels_data, load_generators_availability, load_vre_stor_availability.

[cfe316]

.... I hope that we can change policies from 0/1 to false/true in the future. Or for policies with three or more options (looking at U, UCommit) have them be descriptive strings which translate internally into named constants or enums or something.

[cfe316]

Since you throw an error in the if clause, could the contents of else be moved out of the else and up one indent level? After all, they're on the Happy Path.