Generalization of the CTMRG `state` type

[pbrehmer]

Currently, CTMRG only runs on InfinitePEPS as its state type, and with #111 also on InfinitePartitionFunctions. However, all CTMRG contractions as well as the sparse storage structs in principle support more general objects, such as PEPS-PEPS or PEPS-PEPO-PEPS sandwiches.

In order to generalize the state type that is specified by the user and passed on to leading_boundary we need to agree on a design. Looking at the implementation of CTMRG, it is clear that the type of state needs to support indexing operations and rotations. I think there are at least two options:

1. We could create a PEPSSandwich and PEPOSandwich type. Here the question would be if they should be subtyped as an InfiniteSquareNetwork - this would however somehow create a circular hierarchy in its current state.
2. We could just use tuples of InfiniteSquareNetworks to represent the sandwiches, e.g. Tuple{InfintePEPS,InfinitePEPS}, and define indexing methods such as getindex on them.

Another thing to consider is to relax the InfiniteSquareNetwork interface such that it is understood as an interface which states that can be contracted using CTMRG should support. This would e.g. mean getting rid of the math and OptimKit operations.

See #111 for further comments.

[lkdvos]

Just to make a comment here, I think there are two separate issues you are touching upon.

The first is about data structures, in the sense of how we actually lay out the data as julia structs. There are many options, using tuples or custom structs, and my guess is that the performance implications are completely negligible, so I would just choose the thing that is most easy to interpret as a human. In other words, whatever is the most intuitive for each specific instance should be fine.

A second point is about designing functions. Here, it is a very common pitfall to think in terms of abstract types and type hierarchies, which is I fear somewhat the direction this question is pushing towards. Very often, prematurely restricting the type signature of functions leads to bad code architectures, since you then are effectively designing code around objects. Julia often shines best by not thinking about the data structures at all, and simply ducktyping everything. This means that rather than thinking about what types of arguments the CTMRG routine should accept, it is a lot better to think about what functions the arguments should support.

TLDR: instead of trying to fit everything into abstract types, I would focus more on trying to avoid specializing methods as much as possible, especially the higher level parent methods and only doing that whenever the actual layout of an object is known, writing concrete implementations for leaf methods. That way, we can decide on future additions in the future, and simply implement only the leaf methods whenever needed.