Compatibility with multifusion categories

[borisdevos]

This PR provides the changes required to be able to consider the BimoduleSectors of MultiTensorKit.

All changes boil down to either

1. not being able to evaluate the oneunit of a BimoduleSector, or
2. not being able to use braiding tensors for BimoduleSector GradedSpaces,
   and finding ways around to this.

A potential thing to add is tests with BimoduleSector MPS/MPOs or so? For this, I would need to first complete benchmarking MultiTensorKit, hence the draft PR. I might also need to format.

[codecov]

Codecov Report

❌ Patch coverage is 83.58209% with 11 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/utility/utility.jl	33.33%	4 Missing ⚠️
src/algorithms/fixedpoint.jl	0.00%	3 Missing ⚠️
src/operators/abstractmpo.jl	0.00%	2 Missing ⚠️
...c/algorithms/excitation/quasiparticleexcitation.jl	75.00%	1 Missing ⚠️
src/algorithms/groundstate/gradient_grassmann.jl	0.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/algorithms/ED.jl	100.00% <100.00%> (ø)
src/algorithms/correlators.jl	90.90% <100.00%> (ø)
src/algorithms/excitation/chepigaansatz.jl	91.48% <100.00%> (ø)
src/algorithms/timestep/taylorcluster.jl	100.00% <100.00%> (ø)
src/algorithms/timestep/wii.jl	98.14% <100.00%> (ø)
src/algorithms/toolbox.jl	95.15% <100.00%> (ø)
src/environments/abstract_envs.jl	92.10% <100.00%> (ø)
src/operators/mpo.jl	87.83% <100.00%> (+0.45%)	⬆️
src/operators/mpohamiltonian.jl	90.22% <100.00%> (+0.26%)	⬆️
src/operators/ortho.jl	100.00% <100.00%> (ø)
... and 9 more

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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

[borisdevos]

Wow it's been a while since I messed up so much with git 😅
Multifusion tests fail because IsingBimodule-graded spaces is still a WIP (QuantumKitHub/TensorKit.jl#263).

[borisdevos]

I may have added some confusing terminology with the recent commits, so let me clarify as much as possible.

First of all, I defined a left/rightunit for MPS and MPO. For the MPS this makes most sense, as my virtual space will in general be graded by module objects, so the "coloring" to the left and right of this is different. So in our convention of physical legs down, rightunit captures the coloring of the physical space, while leftunit captures the coloring of auxiliary legs such as in excitations, transfer_spectrum, etc.
For MPOs I'm still on the fence, because while in general my MPO's virtual space can also be graded by module objects, the only thing I've tested up till now is Hamiltonians where it's fully colored by the rightunit of the corresponding MPS. So this notation is introduced to ease notation mostly. I can deal with not having this; this appears only in the keyword argument of exact_diagonalization.

Connected to the last remark, many functions construct an MPS given an MPO based on the latter's virtual spaces. Since the MPOs I've considered up till now don't have different colorings on its virtual spaces, there is currently no difference between the left unit and right unit of an MPO. Thus, there's no difference between the leftunitspace and rightunitspace of the virtual space of an MPO, and I simply systematically chose to put rightunitspace to accentuate the "physicalness" of the coloring.

I've also replaced the remaining oneunits with unitspaces, where I didn't think too hard whether it was a leftunitspace or rightunitspace because I'd have to fiddle a bit everywhere to actually get the information of the coloring (reminder that left/rightunitspace can't be called on a space type), and in my usage I didn't encounter these constructors. If this is wished, I can more extensively test how these behave with a multifusion sector. Most are easy to tell beforehand that they can't be used. For example, anything requiring non-trivial braiding cannot be done.