[IDEA] New project structure for DESDEO

[gialmisi]

• What is the current behavior? Currently, DESDEO is scattered across multiple repositories (the packages): desdeo-problem, desdeo-emo, desdeo-tools, desdeo-mcdm, etc.. This was a nice idea on paper, but in reality, it makes developing DESDEO a nightmare. For instance, when developing features that either depend on, or affect, code from multiple packages, one is often forced to modify a local version of the package (monkey patching), which then leads to dangling changes (i.e., they are out of version control). Moreover, having separate repositories like this also leads to separate documentation, which again, needs to be separately maintained. Not a good time.

• Describe the solution you'd like We should move to a monolithic repository and package for DESDEO. This package would contain all the packages previously mentioned, plus others, like desdeo-api, and packages for other features, like explainablity and group decision-making. Here, package just means a directory containing files with code that fall under the category specified by the package. E.g., problem formulation related code goes to the problem folder. Below is a folder structure of the proposed project structure:

DESDEO (project root)
├── desdeo
│   ├── api
│   ├── emo
│   ├── mcdm
│   ├── problem
│   └── tools
├── docs
│   ├── explanation
│   ├── howtoguides
│   ├── reference
│   └── tutorials
└── tests

  - The above shows only the main directory structure.
  - All configuration files are found at the root level of the structure.
  - The code for the current "packages" are all located in the _desdeo_ folder.
  - documentation and tests are in their own folder as well (_docs_ and _tests_, respectively).

• What is the motivation/use case for changing the behavior? As mentioned, working on and developing DESDEO in its current format is a nightmare. The data footprint of DESDEO will be minuscule compared to some popular Python packages, e.g., numpy, scipy, pandas. There really is no reason to provide separate Python packages in DESDEO. Having the described monolithic structure is also justified because there are very little features in DESDEO that would be truly contained in only one package and not dependent on others. DESDEO has evolved, and a monolithic project structure is needed.

• Describe alternatives you've considered We already tried the alternative of having the packages in their own repositories, and it does not serve our purposes.

• Additional context This is also related to how documentation should be structured discussed in #72 For an in situ example of this structure, see the desdeo2 branch in this repo.