Modular DriverResult

[mrossinek]

What is the expected enhancement?

With #220 coming to an end, the first step of #148 will soon be implemented.
As outlined there, the second step was the investigation of whether the Transformer classes can benefit from these new properties. I.e. the following work flow change:

• Current: Driver -> QMolecule/Watson -> Transformer -> Property -> SecondQOp
• Proposed: Driver -> QMolecule/Watson -> Property -> Transformer -> SecondQOp
  The reason we should investigate this is that we are potentially working towards cutting out the QMolecule/Watson step alltogether (at least from the public API view).

I propose to tackle this issue by introducing a new DriverResult base class:

class DriverResult:
    def __init__(self, ...):
        self.properties: Dict[str, Property] = ...

    @abstractmethod
    def from_legacy_driver_result(result: Union[QMolecule, WatsonHamiltonian]) -> DriverResult:

    @abstractmethod
    def interpret(result: EigenStateResult) -> None:
        # In-place interpretation

We could then have an Electronic(Structure)DriverResult and a Vibrational(Structure)DriverResult. These would gather all the properties which can be extracted from a driver and collects them for further processing by Transformer instances.
These objects would then also be stored in the Problem._molecular_data variables. This would then also allow us to centralize the .interpret() method as part of the properties gathered in each DriverResult rather than having the result_interpreter spread out over the problem modules.

Being containers of all properties available in a calculation, they can be passed to a Transformer granting access to all property data. Assertions on required properties would need to be done by the Transformer instance itself (e.g. if it requires both, ElectronicEnergy and ParticleNumber, etc...)

[mrossinek]

Closed by #263