Full refactoring of run into data

@ndaelman @jrudz , and also @ladinesa @himanel1 @mscheidg

We were talking about a full refactoring of the section run into data. The idea is to slowly build the metadata schema for data maintaining the three main sections: System, Method and Calculation.

The goal is to have normalize() specifically in each of the main sections (with specific defined functions inside), and tackle normalization there (instead of in SystemNormalizer, MethodNormalizer and all the potential list of normalizers for Calculation).

Furthermore, in this refactoring we will heavily clean-up the sub-sections and quantities currently deprecated, unused or wrongly defined in the metainfo.

Lastly, we should also refactor the plugin projects structure (as Pavel pointed out and as we know from the EELSDB parser, it is a bit confusing). An open question here: how much of the current parsers we want to maintain? IMO: we should deprecate some of them, as they are actually empty or only populating very simple metadata.

---

As a dynamic (we can modify this at will):

• Start with System and slowly build the quantities needed to define it.
• After that and add extensive testing, go into Method.
• Finally, we take care of Calculation. This is the most heavily refactored one.

Some simple rules on developing:

• Always add typing for passing arguments to functions.
• Be as general as possible. One of the current problems on run is that some quantities are a bit restrictive because of the packing that was done before; in other words, keep as much as possible a clean class structures (e.g., avoid the Dos or BandStructure current structure).
• Add extensive descriptions in the normalize functions. Be verbose on which quantities are minimal and which ones are extra.
• Always ask for feedback on some unknown quantities.