Add OperatorStyle and GeometryStyle

[AFeuerpfeil]

This PR is the start of some work to make it possible/easier to add custom state or operator types without having to alter their base implementations, and without having to redefine a bunch of functionality that already just works.

The main idea is to avoid having to encode distinctions between finite/infinite or hamiltonian/mpo as hard type constants or abstract types, since this often clashes with Julia's type tree architecture (you cannot subtype multiple things).
Instead the idea is to use traits for dispatching, and gradually start loosening the type restrictions on the inputs of various functions here.

The plan is to gradually start incorporating this strategy, to avoid having a massive PR that has to change everything at once, and keep this non-breaking.
This PR is the first part, which simply introduces the traits.

[codecov]

Codecov Report

❌ Patch coverage is 91.66667% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/utility/multiline.jl	33.33%	2 Missing ⚠️

Files with missing lines	Coverage Δ
src/MPSKit.jl	100.00% <ø> (ø)
src/operators/mpo.jl	87.38% <100.00%> (+0.17%)	⬆️
src/operators/mpohamiltonian.jl	89.96% <100.00%> (+0.05%)	⬆️
src/states/abstractmps.jl	52.32% <100.00%> (-11.21%)	⬇️
src/states/finitemps.jl	94.63% <100.00%> (+0.40%)	⬆️
src/states/infinitemps.jl	76.47% <100.00%> (+0.17%)	⬆️
src/states/multilinemps.jl	75.00% <100.00%> (+1.92%)	⬆️
src/states/quasiparticle_state.jl	86.69% <100.00%> (+0.43%)	⬆️
src/utility/styles.jl	100.00% <100.00%> (ø)
src/utility/multiline.jl	63.63% <33.33%> (-1.75%)	⬇️

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[lkdvos]

Same comment here

[lkdvos]

Except for the comments, looks good to me, I'm happy with this and think it will overall improve the quality of the package.
I am not a huge fan of IsfiniteStyle as a name, since we might want to consider extending this at some point for WindowMPS, so perhaps we could come up with something that is slightly more generic? LatticeStyle, GeometryStyle, ...?

[AFeuerpfeil]

I fully agree with both the comments and the renaming and have changed the PR accordingly.

[AFeuerpfeil]

One question I came up with when rewriting the environment constructors is:
How should we implement the logic that checks that e.g. above, below, operator all have the same GeometryStyle?

In order to not always have to write e.g.

@assert allequal([GeometryStyle(above),GeometryStyle(below),GeometryStyle(operator)])

I would argue for overloading e.g. Base.:& to add this logic in the following way:

Base.:&(::FiniteStyle, ::FiniteStyle) = FiniteStyle()
Base.:&(::InfiniteStyle, ::InfiniteStyle) = InfiniteStyle()

Then, one can call

geometry_style = GeometryStyle(above) & GeometryStyle(below) & GeometryStyle(operator)

which will either give the common style of the 3 or error, if they are not identical. (If we want to throw a specific kind of error, one can also overload

Base.:&(::FiniteStyle, ::InfiniteStyle) = throw(...)
Base.:&(::InfiniteStyle, ::FiniteStyle) = throw(...)

[github-actions]

Your PR no longer requires formatting changes. Thank you for your contribution!

[VictorVanthilt]

Just looked through the PR and talked to @lkdvos. I like this idea and support it being added to the code, provided that someone is appointed to actually do all the other changes to accomodate this idea :) .

[AFeuerpfeil]

I am currently already working on implementing the changes.
I am done with states, operators and environments and am currently applying them to the algorithms.
When this PR is merged, I will start making small and hopefully non-breaking PRs that change parts of the code.

[lkdvos]

I've pushed some final changes to the formatting and docstrings, to address the comment about MPO style referring to transfer matrix.
Once the tests turn green, I will merge this.