Simple multifusion example for testing

[borisdevos]

In light of the discussion at QuantumKitHub/TensorKit.jl#247, this PR implements the multifusion category $$\mathsf{Rep} Z_2 \oplus \mathsf{Rep} Z_2 \cong \mathsf{IsingAnyon}$$ to allow for testing the proposed fusion tree manipulations changes. Since MultiTensorKit itself relies on TensorKit, this example had to be worked out in TensorKitSectors.

Since the main purpose is for testing, I may have cut some corners. In particular:

1. The CatType type is quite messy, in the sense that I had to export some cursive letters so that parsability was guaranteed. I could change CatType to take on integer values, and then remove the custom Base.show. I cut this corner somewhat because I assumed no-one would actually use this category in TensorKit without MultiTensorKit, but I am also contradicting myself by actually exporting these.
2. The Nsymbol function is not as clean as in MultiTensorKit, because I didn't want to effectively work with the same struct design as BimoduleSector, namely 3 integers to uniquely specify an object.
3. No docstrings.
4. Due to the identification with IsingAnyon, I didn't bother with the unitarity, pentagon and hexagon tests.
5. Not really a cut corner, but the value iterator tests might not really make sense. Sure, I defined the SectorValues properties, but the ordering of the objects is irrelevant to the properties of the multifusion category. Maybe I'm looking too much into this from the maths perspective, since this is probably just a programming thing.

Let me know which aspects I shouldn't have neglected.

[codecov]

Codecov Report

Attention: Patch coverage is 92.50000% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/multifusion.jl	92.50%	3 Missing ⚠️

Files with missing lines	Coverage Δ
src/TensorKitSectors.jl	20.00% <ø> (ø)
src/multifusion.jl	92.50% <92.50%> (ø)

🚀 New features to boost your workflow:

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

[borisdevos]

For now I'll let Nsymbol error when the fusion is forbidden. If we want to change this to return false, this is a simple change but will also require slight modifications in the tests. I guess figuring out where the formatter is upset is the last thing to do?

[lkdvos]

I'm a bit on the fence about the current implementation.
It seems to me like the CatType is definitely a bit convoluted for this simple case, and given that this doesn't generalize very well either I think this is code complexity that doesn't help too much (which is a liability for maintenance in the long term...)
I also don't think the show is a very good argument, I honestly don't think this is all that legible anyways.
I might feel a row and col are a bit clearer too, since that makes it very explicit what "colors" are allowed.
On the other hand, I also don't want to (or want you to) have to spend too much time refactoring this either, if it works then why not.

For testing purposes, it might make sense to just simplify this and use the IsingAnyon equivalence a bit more thoroughly, with the correct limitations of erroring for the functions that should. For example, we could simply store an IsingAnyon + Bool flag to indicate either C,M or D,Mop as well.

Ultimately, I guess the main purpose is to have a sector that errors whenever you do an operation that isn't allowed, just to check that TensorKit is compatible with that. Therefore, I would want this to be as minimal as possible, since we won't really be using that for anything else (?) and I don't want to deal with maintaining that code.

[borisdevos]

Apparently, I'm testing the custom 3-argument show incorrectly. I first tried e.g.

julia> Mop = IsingBimod(2,1,0)
julia> @test eval(Meta.parse(sprint(show, Mop))) == "ℳᵒᵖ[0]"
Test Failed at REPL[46]:1
  Expression: eval(Meta.parse(sprint(show, Mop))) == "ℳᵒᵖ[0]"
   Evaluated: IsingBimod(2, 1, 0) == "ℳᵒᵖ[0]"

Also, formatting remains an issue

[Jutho]

The goal of my suggestions is to get rid of isM, isMop, isC and isD completely, as I don't like those names very much as they are very short and look weird (a very scientific reason, I know). ismodulecategory can stay if needed, but if the implementation also doesn't need it, then all the better 😄 .

[lkdvos]

I made some formatting changes and simplified the sorting, the only thing I'm still not sure about is the printing. Honestly, I think IsingBimod(row, col, label) is probably more helpful anyways so I would suggest simply removing that.

[lkdvos]

I'll merge this and tag it as soon as the final round of tests pass. Thanks for working through the details, I think it looks very clean and maintainable now.