Fix handling of real tensors with complex scalartype

[lkdvos]

This is an attempt at being more principled about dealing with complex sectorscalartypes with tensors that don't necessarily have complex entries.
In the context of #356 I bumped into a couple of these, so I figure might as well look a bit more carefully at the various occurrences.

My general strategy here is to use TO.tensoralloc_add as much as possible, since we already fixed this issue in that function.
However, I also had to modify compose_dest, since there are no recouplings required there, and therefore there is no need to update the scalartype.

I also added the utility check_spacetype function that does exactly what you suspect it does, and just centralizes various places in the code where this was in use.

[Jutho]

Haven't managed to go through this in detail, but I wonder if before trying to fix this and make it consistent, it might be useful to first settle the question if we want to separate between fusionscalartype and braidingscalartype? I think it is a valid request to use e.g. FibonacciAnyon in a context where there will be no braiding (e.g. golden chain), and therefore to only use real numbers.

[lkdvos]

I think in general I completely agree to introduce these functions and make that distinction.
I'll get started on that, but I don't think it hurts to already merge this since it does fix the problem, albeit not in the most efficient way.
I would in any case much rather have something that too eagerly becomes complex instead of errors out.

[lkdvos]

QuantumKitHub/TensorKitSectors.jl#62

[codecov]

Codecov Report

❌ Patch coverage is 95.00000% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/spaces/vectorspaces.jl	80.00%	1 Missing ⚠️
src/tensors/indexmanipulations.jl	96.15%	1 Missing ⚠️
src/tensors/tensor.jl	0.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/planar/planaroperations.jl	72.79% <100.00%> (ø)
src/tensors/abstracttensor.jl	58.89% <ø> (ø)
src/tensors/diagonal.jl	91.54% <100.00%> (+0.30%)	⬆️
src/tensors/linalg.jl	82.64% <100.00%> (ø)
src/tensors/tensoroperations.jl	97.46% <100.00%> (-0.03%)	⬇️
src/spaces/vectorspaces.jl	84.68% <80.00%> (+1.35%)	⬆️
src/tensors/indexmanipulations.jl	73.33% <96.15%> (+0.29%)	⬆️
src/tensors/tensor.jl	85.47% <0.00%> (-0.49%)	⬇️

🚀 New features to boost your workflow:

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

[borisdevos]

fusionscalartype and braidingscalartype can also be used in many more places than the one time here in the twist! change, so I agree with Lukas.

[lkdvos]

@Jutho, I think I somewhat centralized determining the scalartype now, and in principle this is ready to start an attempt to make Fibonacci anyons retain their real element types through a variety of methods. However, this also requires making that change in a number of the fusion tree manipulations, which I don't want to touch here because that will interfere with the work in #261. I would suggest that for now it is better to simply merge this in its current state, and leave that as an open issue to tackle after the fusiontree vectorization stuff is finished.