Verify consistency of implementation of `ProjOuterProdTTN` with `ProjTTN`

In #132, the functionality of representing an operator of the format O=A|v><v|A^dag is introduced with ProjOuterProdTTN, which should behave consistent with ProjTTN for a general operator W. This type supersedes ProjTTNApply which was designed to give access to environments of A|b>, with A::AbstractTTN,B::AbstractTTN projected into the n-site tangent-space of another psi:AbstractTTN (the latter being the one which is usually optimized, e.g. in the case of variational compression of A|b>). The original functionality of ProjTTNApply is available for ProjOuterProdTTN via contract_ket instead of the usual contract.
Going forward, it should be checked whether the definitions and functions of ProjOuterProdTTN are designed transparently, or whether there are logical inconsistencies inherited from the design of ProjTTNApply. Furthermore, tests should be added as to whether complex arguments are handled properly (current tests are performed on real-valued AbstractTTN as input).
It would make sense to adress this together with #133.

Start by comparing the definitions and functions of ProjOuterProdTTN with ProjTTN, then review ProjTTNApply and the contract_ket path for inherited inconsistencies. Add coverage for complex-valued AbstractTTN inputs and verify behavior against the existing real-valued tests, coordinating scope with issue #133.