Parallel years cleaning : few removal of "numspace"

[guilpier-code]

See ticket #1751

For now, just a first analyze of how we could do to isolate years (from the simulation and what should not be inside a year).
We take advantage of this to make some removals of numSpace.

Comments :

• year job and simulation are really intertwined, this is a first and important reason why a year are not isolated.
  For instance, when running a year of simulation, we call a function of the simulation object, not of the year object.
• although what we first thought, each year job creates a fresh new weekly optimization solver object. This object solves every week problem, using the previous week's optimization solution as a base. Before creating a solver object, a year first destroys the previous year's solver (as well as the start base it holds).
• I've heard that CI tests for parallel (currently passed at night run) don't generate the same output results as the same tests run in sequential. We assumed that it was because of the bases. Indeed, if the same simulation year is run starting from 2 different bases, it can lead to different simulation results. But given the previous point, that's not true : the simulation results should be identical whether we run a simulation sequentially or not. We may have broken something in the parallelism by not testing the it on CI.

Goals :
We want to isolate year jobs to make cleaner parallelism.
Each year job should be designed so that it can be run in a thread independently from any other year job.
In particular, a year job should hold its own memory spaces, and not shared memory as done currently.

[guilpier-code]

This function (PrepareDataFromClustersInMustrunMode) has many drawbacks :

• It's too long
• It's supposed to offer a treatment common to mode adequacy and economy but its body clearly separates adequacy mode and the other modes (economy)
• it's complicated : for example, we have 2 loops over thermal clusters of an area, though we could only have one.

So we removed this function from common-eco-adq.cpp and put down these calculations in specialized functions associated to each simulation mode.

[flomnes]

See #2168

[flomnes]

Thanks for the awesome work @guilpier-code ! Can you split this PR in 2 ? The double count issue for adequacy needs a bit more investigation

[sonarqubecloud]

Quality Gate failed

Failed conditions
D Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint