Add sectorscalartype

[lkdvos]

This is a minor change that centralizes the determination of the eltype of the topological data.
This simplifies some of the fusion tree manipulations, as it makes it easier to determine the output type.

Additionally, this also provides a hook for types that don't necessarily want to have Fsymbol(one(I), one(I),....), either because it is not efficient, or because one(I) is hard to determine (multi-fusion stuff).

Finally, it could also provide a starting point for having sectors with different eltypes, as one could imagine wanting SU2 symbols with BigFloat precision etc.

I tried to not change too much, but left a couple comments in the code about things I am unsure about. We should probably also discuss the fusion tree manipulations constructions, as the @isdefined construction might not be necessary now. I don't know if this has performance implications (either on the compiler or at runtime), but it might just be slightly more readible as well.

[codecov]

Codecov Report

Attention: Patch coverage is 93.75000% with 1 line in your changes missing coverage. Please review.

Project coverage is 79.95%. Comparing base (54f2672) to head (d0d49eb).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/fusiontrees/manipulations.jl	93.75%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #146      +/-   ##
==========================================
- Coverage   79.97%   79.95%   -0.02%     
==========================================
  Files          42       42              
  Lines        4983     4974       -9     
==========================================
- Hits         3985     3977       -8     
+ Misses        998      997       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Jutho]

This is a good approach to eliminate all my one(I) calls, which will indeed be necessary for multifusion stuff. I am not quite sold yet on the Feltype and Reltype name. Unlike Fsymbol and Rsymbol, I feel like pronouncing this is Fel-type and Rel-type. Maybe Fscalartype and Rscalartype suffer less from this?

[lkdvos]

As discussed, I now replaced everything with just a unified sectorscalartype. I started going through removing the @isdefined calls, but actually it is not that elegant, as the SingletonDicts don't really support pre-initializing the dictionary. I think it really is better to just leave them for now.

If tests turn green, this is good to go for me.

[Jutho]

I am wondering to what extent it would be an abomination to replace sectorscalartype(somesectortype) with simply scalartype(somesectortype)? It is not really a correct application of method overloading, as it is definitely changing the way/meaning of scalartype from its original intention. But sectorscalartype(somesectortype) sounds like overkill.

[lkdvos]

I have to admit that this also crossed my mind, however I was a bit worried about something like a vector of sectors which suddenly has scalartype Float64, and then the default definition of zerovector might return a vector of floats (although I did not test if this is actually the case).
In the end, it doesn't matter too much, I don't think many external users would use this, so maybe we shouldn't even export it

[Jutho]

Yes you are right that this will cause unforeseen problems further on. By lack of a better suggestion I will merge as is.