Kets : support SMatrix eltype

[pablosanjose]

After #80 we lost the ability to use a ket in KPM calculations with an SMatrix eltype. We were restricted to scalar eltypes for Hamiltonians with scalar eltypes and Quantica.orbitaltype(h)::SVector eltype otherwise. However, it is useful to allow kets with SMatrix eltype, as an extension of the SVector eltype. It is useful when using randomkets and wanting to have some correlation between individual random kets. Then, instead of N correlated random kets we can have a single one with SMatrix eltype.

Example (relevant for Nambu stochastic trace KPM)

h = LatticePresets.honeycomb() |> hamiltonian(hopping(I), orbitals = Val(2)) |> unitcell(100) |> unitcell
k = randomkets(n, r -> cis(2π*rand()) * SA[1 0; 0 -1])
dosKPM(h, kets = k)

Note that Matrix(k, h) is actually an N×n matrix (where N == nsites(h)) with eltype <:SMatrix{2,2}. This is equivalent to two random vectors with <:SVector{2} eltype (since we have two orbitals per site in h), but their elements are correlated. If one has element SA[x; 0] the other has SA[0; -1] on the same site.

Internally this comes with several changes. For one, we now allow resolveing KetModels and TightbindingModels as a whole (not only the selectors of their individual model terms), so that we can resolve them only once and them pass them on to be applied in a hot loop without needing to resolve term by term. This was an optional change, but it seemed worthwhile, and might be used to clean up also some other parts of the code. We also created a new type of iterator SiteSublats for combined site index and sublattice. Again this could be used in other parts of the code.

All in all, those changes can be viewed as creating a little bit of bloat in the code. We should in particular remember to revisit this in the future, and perhaps try to simplify the ResolvedSelector design somewhat...

[pablosanjose]

Ah, another thing: currently Matrix(ketmodel, hamiltonian) is non-inferrable. It doesn't seem to induce a performance penalty, but it might be worth looking into before merging

[codecov-commenter]

Codecov Report

Merging #99 into master will increase coverage by 0.35%.
The diff coverage is 76.62%.

@@            Coverage Diff             @@
##           master      #99      +/-   ##
==========================================
+ Coverage   62.01%   62.36%   +0.35%     
==========================================
  Files          16       16              
  Lines        2651     2676      +25     
==========================================
+ Hits         1644     1669      +25     
  Misses       1007     1007              

Impacted Files	Coverage Δ
src/iterators.jl	69.64% <28.57%> (-1.79%)	⬇️
src/model.jl	72.66% <62.50%> (+0.11%)	⬆️
src/lattice.jl	81.59% <75.00%> (+0.06%)	⬆️
src/hamiltonian.jl	76.17% <86.95%> (+1.34%)	⬆️
src/tools.jl	57.08% <100.00%> (+0.74%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 900c6fc...a4dbc4d. Read the comment docs.