Remove MPSKitModels dependency

[Yue-Zhengyuan]

This PR removes MPSKitModels dependency. The main purpose is to use pre-defined operators from TensorKitTensors.

• Now all Hamiltonians are decoupled from the ones from MPSKitModels.
• The general machinery on AbstractLattice is lost. But I think this will eventually be replaced by TiledArrays?

Some issues that are addressed:

• J1-J2 model shouldn't have spin U(1) symmetry with sublattice = true (S_xx, S_yy with U1Irrep symmetry MPSKitModels.jl#57). With TensorKitTensors, an error will be correctly raised.
• pwave_superconductor is actually a p-ip (instead of p+ip) wave Hamiltonian. I wonder if we want to change the convention and update the benchmark energy in the test.

[codecov]

Codecov Report

❌ Patch coverage is 64.86486% with 13 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/operators/models.jl	64.86%	13 Missing ⚠️

Files with missing lines	Coverage Δ
src/operators/lattices/squarelattice.jl	95.00% <ø> (ø)
src/operators/models.jl	75.00% <64.86%> (-5.49%)	⬇️

🚀 New features to boost your workflow:

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

[lkdvos]

Definitely in favor of using TensorKitTensors for the operators, but I'm not entirely sure if we gain a lot by decoupling the actual models. The main thing I worry about is that there are now two functions for each model, and you have to remember that PEPSKit.hubbard_model !== MPSKitModels.hubbard_model.

We should however probably discuss this in a bit more detail together, since I agree that the MPSKitModels package is a bit awkward. I would be happy to include most of that functionality in MPSKit, for example, since I feel like it does not actually warrant a separate package, but in that case probably we should move out the lattice stuff in a different package (ie. TiledArrays/LatticeArrays or something similar).

[Yue-Zhengyuan]

you have to remember that PEPSKit.hubbard_model !== MPSKitModels.hubbard_model.

This is easy 😂 Actually for newcomers I don't think they expect MPSKitModels to provide 2D Hamiltonians?

[lkdvos]

Well, the point is that if you accidentally do something like using MPSKitModels, PEPSKit, since both these functions are exported and have the same name, we now get a clash, your REPL will probably spit out some warnings, and you now have to explicitly qualify from which you want to import the function. I'm not saying this is horrible, but this is definitely a breaking change, and I'm not entirely sure what we are gaining by not including MPSKitModels, since we depend on MPSKit anyways

[Yue-Zhengyuan]

you now have to explicitly qualify from which you want to import the function

Before TensorKitTensors exists, I needed to import MPSKitModels to access pre-defined operators in order to define custom Hamiltonians. This was already causing a name clash on LocalOperator, and I have to explicitly write using PEPSKit: LocalOperator. But now we can import TensorKitTensors instead, so one big reason to import both MPSKitModels and PEPSKit is gone.

this is definitely a breaking change, and I'm not entirely sure what we are gaining by not including MPSKitModels, since we depend on MPSKit anyways

Dependence on MPSKit is quite reasonable, since it should be common knowledge that PEPS can be contracted with boundary MPS methods. But getting PEPSKit Hamiltonians from MPSKitModels has always weirded me out.

After rewriting the Hamiltonians with TensorKitTensors, what remains that still depends on MPSKitModels is just the AbstractLattice stuff. Since we are currently supporting square lattice only, I think it's not worth it to keep depending on another package that is not designed to work with PEPS. Although this will be a breaking change, the function signatures remain untouched, so the difference is not that dramatic.