Refactor Arithmetic Operations on AmplitudeVector

[jonasleitner]

This PR refactors the arithmetic operations implemented on the AmplitudeVector class such that missing blocks are consistently treated as zero blocks.

Previously, this was only the case for __add__, while the other operations employed __forward_to_blocks, which raised an exception for differing blocks. Moreover, dot showed inconsistent behavior, ADC1.dot(ADC2) gave the ph overlap, while ADC2.dot(ADC1) raised an exception due to a missing pphh block. The in-place operators, also employed __forward_to_blocks, which created a new AmplitudeVector instance and thus were not really in-place.

In this PR I explicitly implemented the arithmetic operations ensuring that inputs and result don't share memory (libadcc.Tensors are copied if necessary). Moreover, in-place operations mutate the current instance modifying/deleting existing blocks.
Finally, type hints are introduced throughout AmplitudeVector.py

A Note on the reflective operations:
libadcc.Tensor * Amplitude (same for other operations) is not possible, since the backend raises a TypeError. Thus, __rmul__ etc. are not reachable for this case and the implementation contains in principle dead code.

[frieschneider]

We would currently mix plain np.ndarray and parameterized np.ndarray[...]. I would prefer the parameterized form where possible. For example, ElectronicTransition.py uses the unparameterized form.

What do you think @jonasleitner ?

[jonasleitner]

I also prefer the parametrized form including shape and optionally the data type. However, I would suggest to resolve this at a later stage once we revisit the corresponding files regarding type hints?