Implement Styles for AbstractMPS

[AFeuerpfeil]

This PR implements the methods AC2, dot, isapprox, norm, normalize(!) as well as the left and right fixedpoints for an AbstractMPS by dispatching on GeometryStyle. These functions are currently defined for FiniteMPS and InfiniteMPS. For other types of AbstractMPS, there exist more specialized functions, so the dispatch on GeometryStyle is skipped making these changes non-breaking.

Examples for the Style system are

function TensorKit.dot(::FiniteChainStyle, ψ₁::AbstractMPS, ψ₂::AbstractMPS)
    #todo : rewrite this without having to gauge
    length(ψ₁) == length(ψ₂) || throw(ArgumentError("MPS with different length"))
    ρr = TransferMatrix(ψ₂.AR[2:end], ψ₁.AR[2:end]) * r_RR(ψ₂)
    return tr(_transpose_front(ψ₁.AC[1])' * _transpose_front(ψ₂.AC[1]) * ρr)
end

for the FiniteMPS and

function AC2(::InfiniteChainStyle, ψ::AbstractMPS, i::Integer; kind = :ACAR)
    if kind == :ACAR
        return ψ.AC[i] * _transpose_tail(ψ.AR[i + 1])
    elseif kind == :ALAC
        return ψ.AL[i] * _transpose_tail(ψ.AC[i + 1])
    else
        throw(ArgumentError("Invalid kind: $kind"))
    end
end

for the InfiniteMPS.

[codecov]

Codecov Report

❌ Patch coverage is 97.36842% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/states/abstractmps.jl	94.44%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/states/finitemps.jl	95.00% <100.00%> (+0.36%)	⬆️
src/states/infinitemps.jl	76.11% <100.00%> (-0.36%)	⬇️
src/states/abstractmps.jl	66.01% <94.44%> (+13.69%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lkdvos]

I'm a bit confused by the choice of methods you choose to dispatch through the style.

I was expecting this to be more applicable to the higher-level functions, rather than these very low-level functions instead. Note for example that you are still assuming that the AbstractMPS has fields AC and AR etc, so this isn't necessarily "generalizing" the implementations all that much.

Also for the normalize! function I'm a bit surprised, since in principle that isn't even very well-defined for the infinite case to begin with.

We can maybe rediscuss this a bit more on Monday, but I feel like in general this might not be the right kind of functions to look at, and rather we should focus on the larger algorithms instead.
Note that the goal is not to push everything through the styles, this really only makes sense if we can find implementations that are generic enough to begin with, since otherwise we will have to overload each specific case anyways.

[lkdvos]

Is there a benefit to having this go through the geometrystyle? It looks like we end up with the same fallback anyways, so I don't really see the point here