Reworked internals

[RobinGeens]

This branch holds many many changes to the internals of Zigzag, though the functionality itself has barely changed. Changes include the following:

• Fully rewrite (User) Spatial Mapping Generator
• Force typehints everywhere and test with dynamic type checking
• Represent Layer Dimensions, Operands, Operational Array Dimensions, etc... with classes instead of strings
• Encapsulate most of the Layer Attributes in classes
• Equip a LayerAttributes class with methods to parse user input
• Provide an abstract base class for Workload and CME
• Transfer the functionality of adding CMEs to a CumulativeCME class
• Simplify the file structure.

The proposed dev setup, to be used by all future contributions, is as follows:

• Use the .pylintrc file from .github/workflows/. This is the one from the Google style guide, but with a line length of 120
• Use strict static type checking: "python.analysis.typeCheckingMode": "strict", in .vscode/settings.json
• Test with Typeguard (dynamic type checking).

To complete this PR, the following to do's should be completed. Currently, only the test_origin tests pass.

• [ ] Review the new code
• [ ] Repair the following files and provide type annotations: PEArrayScalingStage.py, SearchUnusedMemoryStage.py, RemoveUnusedMemoryStage.py, GeneralParameterIteratorStage.py, AimcArray.py, DimcArray.py, imc_unit.py, ImcArray.py
• [ ] Run the tests, other than test_origin
• [ ] Replace the hardcoded energy and latency values in those tests. With the new SpatialMappingGenerator, the results are slightly better
• [ ] Test whether CACTI runs as expected
• [ ] Update the docs

To come to a more uniformly programmed code base, I would like to suggest the following programming principles:

1. A good function should do one thing and one thing only. As such, a good function cannot reasonably be separated into multiple blocks, as this implies the function does more than one thing.
2. Function and variable names should be clear enough such that a comment to describe it is redundant. With well-chosen function and variable names, it is easy to follow the programming flow without reading additional comments.
3. Comments should give a rationale, and not explain the code itself.
4. Avoid try/except blocks for control flow, these should only be used for error handling and irregular behavior.

Note that after this PR, I will be reworking the user interface.

[RobinGeens]

This is a perfect list of how this PR had to be split up 🥲 . Right now, if someone disagrees with a certain part, it's very hard to filter it out. It is also very difficult to see what diff corresponds to what feature change.

Agreed, will keep this in mind next PR :)

Not everybody uses VSCode :), if you want to enforce type checking, I suggest adding the pyright configuration (which can be detected by VSCode) in the pyproject.toml

Fair point, thanks for the remark!