Gaussian basis set handling: aiida ORM types and electron edits should be decoupled

[blokhin]

There is an architectural issue, as aiida_crystal_dft.data.basis.CrystalBasisData has double responsibilities:

• accommodating Aiida ORM
• editing electron initial distribution and dumping the content

Ideally, they should be decoupled from each other as it allows more granular usage.

cf. #34

[ansobolev]

The problem here lies in the aiida architecture: when the workflow is submitted, all the objects are serialized to DB, and then get deserialized in their turn, so that they can call the code that belongs to them, hence, it's not easy to call another function that doesn't belong to serialized object, as it's quite difficult to tell from outside, what data was serialized. Moreover, setting oxidation state involves heavy use of the inner dict and alters the innards of the basis object, so it belongs to the object. It can be noted, that the function is rather top-level, all the calculations belong elsewhere.

[blokhin]

Let me re-phrase. Is it possible to use that code bypassing AiiDA? e.g. to change the oxidation states in a structure