Do not allow duplicate levels in anyonic braid

[borisdevos]

Previously, equal levels were allowed to be passed to braid, which would then silently overbraid. The docstring was not clear about this being allowed, so I changed some things to just simply forbid it. There were also some inconsistencies in docs/docstrings on how to interpret levels, so now I put "depths" everywhere as the synonym to them.

[lkdvos]

As you can tell in the braidingtensor implementation, I was actually making use of the fact that you only need distinct levels for legs that will actually cross. This might actually be a useful feature at some point, since in principle we could envision designing an ITensor-like system that holds on to space,level and and id, and at that point it might be annoying to ensure uniqueness.

As an alternative, how about within the actual braiding code where we check which level is larger we add a check that they are not equal whenever the braiding is not symmetric?

[borisdevos]

The only downsides here are that the error will be raised much deeper, and that you can do bad homspace braids, but I can live with that :)
I believe with this that NoBraiding also still works fine, but that's untested.

[lkdvos]

So reading this in a bit more detail, I think the goal has always been to have levels refer to a height, so larger values braid over lower values, and I guess the implementation was wrong (I'm also not entirely sure if we have anything that can test this, as of course this is just the same as using the timereversed category)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
src/auxiliary/auxiliary.jl	94.54% <100.00%> (+0.66%)	⬆️
src/fusiontrees/braiding_manipulations.jl	95.16% <100.00%> (+0.07%)	⬆️
src/tensors/indexmanipulations.jl	88.35% <ø> (ø)

🚀 New features to boost your workflow:

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

[borisdevos]

So reading this in a bit more detail, I think the goal has always been to have levels refer to a height, so larger values braid over lower values, and I guess the implementation was wrong (I'm also not entirely sure if we have anything that can test this, as of course this is just the same as using the timereversed category)

This is in contrast with the one example in the docs, where level = depth (it's mentioned literally in the text below the image). So that's why I changed everything to be consistent with depth.

The current implemenation checks inv = levels[s] < levels[s+1] at fusion tree level, which I think doesn't get changed from the pass at tensor level. As far as I can tell, braid -> braid! where the tuple gets split up into 2 tuples for the codomain and domain (pure regrouping), and within fsbraid the domain levels get reversed for the all outgoing convention. So levels is always depths.

[lkdvos]

Well, in that case maybe it's just my brain that always translated it to heights. Good catch, in that case I absolutely agree the language should become depths ;)

[lkdvos]

Left some minor comments about wording, otherwise good to go for me!