Introduction of Property objects

[mrossinek]

Summary

This is a very early WIP for #167.

Details and comments

As proposed in the aforementioned issue as well as the Epic #148, we want to introduce some modular Property objects, in order to containerize the QMolecule and make it fit better into the rest of the updated stack. This PR will make the first step into this direction. Below is a list of the changes:

• Add Property objects for:
  • ElectronicEnergy
  • ParticleNumber
  • AngularMomentum
  • Magnetization
  • DipoleMoment
  • whatever comes out of the WatsonHamiltonian
• generalize the electronic integrals to n-body terms
• provide the means for arbitrary (almost) orbital basis transformation (at least the addition is of new bases is straight forward via the Basis(Enum))
• leverage @jlapeyre's 2-body integral symmetry utilities as part of _2BodyElectronicIntegrals (EDIT: postponed)
• tie the properties into the StructureProblems:
  • electronic (partially done, not very nice atm)
  • vibrational
• add unittests
• add documentation

The tying into the Problem classes will be improved in the future. The details of that implementation depend on steps outlined in #148. The same goes for the interpret() method stubs. I have them there right now because I think they could fit well, but they will only become useful if/once we reach the last implementation step.

⚠️ The API of this PR is by no means final. Public/private methods are bound to change. So are the names of all classes and methods.

[mrossinek]

I started working on the WatsonHamiltonian and Bosonic/HarmonicBasis equivalents for this framework. As its not really fitting together yet I have not pushed these yet but I will update it here tomorrow. In the meantime hopefully the CI passes now.

[mrossinek]

More WIP commits. Things I am not yet satisfied with/sure about which need to be addressed as part of this PR:

• the Basis handling (still not perfect but good enough for this first part of a series of PRs)
• the fact that DipoleMoment contains all three axes without subcomponents

Things that will likely be addressed in the future:

• some properties are mostly copied from the previously existing integral calculators. However, in some cases the label could be constructed directly in a simpler fashion
• the interpret method stubs will only be useful if we proceed with steps 2 and 3 of QMolecule Design  #148
• if we do decide to go there, we probably need an overall container of these properties. This is what ElectronicDriverResult and VibrationalDriverResult may become

All requested changes are implemented.

[dlasecki]

Can we introduce a special type to avoid accessing by an index?

[mrossinek]

Not really. This tuple of matrices gets stored in the base class ElectronicIntegrals. It's length depends on which subclass we are dealing with (length is 2 in OneBodyElectronicIntegrals but 4 in TwoBodyElectronicIntegrals). Introducing a special type (e.g. a NamedTuple) would require registering this type in the base class which would need to be updated when we decided to add e.g. ThreeBodyElectronicIntegrals.

Given that the length and type of the matrices is asserted at construction time (I extracted the validation methods as you suggested above) I think this is okay as is.