Add full update algorithm

[Yue-Zhengyuan]

This PR adds the core part of the fast full update (arXiv 1503.05345) algorithm. Compared to simple update, the environment around a bond to be updated is more accurately represented by the CTM tensors, instead of diagonal weight matrices.

Limitations:

• The implementation assumes square lattice geometry.
• As in simple update, I made some requirements on whether certain virtual spaces of iPEPS tensors are dual spaces.
• The current implementation can currently only calculate models with nearest neighbor interaction only. Support for next nearest neighbor terms (see arXiv 1711.07584) will not be implemented in near future.

Things to do before merging:

• Find a robust criterion to change the evolution time step and determine convergence. Currently, the FU stops when the energy is no longer decreasing. However, I feel that this may prevent the algorithm to evolve out from a local minimum. It may be better if some singular value spectrum can be used to determine convergence (as in CTMRG and simple update).
• Add support for bipartite iPEPS (currently for 2 x 2 unit cell, the algorithm cannot keep the bipartite structure).
• Add a non-trivial test or example.
• Improve docstring.
• Use Julia's more advanced logging system.

[codecov]

Codecov Report

Attention: Patch coverage is 10.48387% with 222 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/time_evolution/fullupdate.jl	0.00%	102 Missing ⚠️
src/algorithms/time_evolution/fu_optimize.jl	0.00%	91 Missing ⚠️
src/algorithms/time_evolution/fu_gaugefix.jl	0.00%	26 Missing ⚠️
src/algorithms/time_evolution/simpleupdate.jl	66.66%	2 Missing ⚠️
src/algorithms/ctmrg/sparse_environments.jl	0.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/PEPSKit.jl	87.50% <ø> (ø)
src/algorithms/contractions/ctmrg_contractions.jl	66.89% <100.00%> (ø)
src/algorithms/ctmrg/sequential.jl	98.36% <100.00%> (+0.08%)	⬆️
src/states/infiniteweightpeps.jl	93.33% <100.00%> (ø)
src/utility/util.jl	51.85% <100.00%> (-0.28%)	⬇️
src/algorithms/ctmrg/sparse_environments.jl	30.76% <0.00%> (ø)
src/algorithms/time_evolution/simpleupdate.jl	87.23% <66.66%> (-0.68%)	⬇️
src/algorithms/time_evolution/fu_gaugefix.jl	0.00% <0.00%> (ø)
src/algorithms/time_evolution/fu_optimize.jl	0.00% <0.00%> (ø)
src/algorithms/time_evolution/fullupdate.jl	0.00% <0.00%> (ø)

[Yue-Zhengyuan]

Some recent design thoughts inspired by YASTN:

The FU consists of two parts - updating the two tensors connected to a bond, and then updating the surrounding CTM tensors. When updating the two tensors, there can be multiple ways to build the environment around the bond (called the "bond metric" in YASTN). The usual FU use the CTM tensors as the environment, but there is a cheaper method (but still more accurate than SU) called the Neighboring Tensor Update (NTU). There, the bond metric is the exact contraction of a few neighboring tensors, like:

          (-1 +0)══(-1 +1)
             ║        ║
   (+0 -1)═══Q0══   ══Q1═══(+0 +2)
             ║        ║
          (+1 +0)══(+1 +1)

or approximate contraction (using boundary MPS approach) of a relatively larger portion of the network around the bond, like:

    (-2 -2)═(-2 -1)═(-2 +0)══(-2 +1)═(-2 +2)═(-2 +3)
       ║       ║       ║        ║        ║        ║
    (-1 -2)═(-1 -1)═(-1 +0)══(-1 +1)═(-1 +2)═(-1 +3)
       ║       ║       ║        ║        ║        ║
    (+0 -2)═(+0 -1)════Q0══   ══Q1═══(+0 +2)═(+0 +3)
       ║       ║       ║        ║        ║        ║
    (+1 -2)═(+1 -1)═(+1 +0)══(+1 +1)═(+1 +2)═(+1 +3)
       ║       ║       ║        ║        ║        ║
    (+2 -2)═(+2 -1)═(+2 +0)══(+2 +1)═(+2 +2)═(+2 +3)

There is a large family of such of bond metrics in the YASTN documentation. Thus we may need to write the first part of FU in a more general manner that accepts different kinds of bond metrics, in preparation of adding NTU in the future.

[lkdvos]

It might already be possible to achieve something like this by simply restricting the number of iterations in the CTMRG contraction. This is definitely not fully equivalent, so I agree that it would be beneficial to have an abstraction to allow different algorithms there.