indices kwarg in selectors

[pablosanjose]

Closes #82

This PR implements the indices kwarg in Selectors, and in doing so introduces some heavy refactoring of the whole Selector engine. See the updated siteselector and hopselector docstrings for details.

We now have ResolvedSelector in addition to SiteSelector and HopSelector. ResolvedSelector is produced by resolve(::Selector, ::AbstractLattice), which now simply replaces sublat names with sublat indices, but does not do any further clever transformation of selection specs (i.e. things like (:A, :B) => (:C, :D) become (1,2) => (3,4), but not (1=>3, 1=>4, 2=>3, 2=>4) anymore). The actual interpretation of the different selector directives is done when querying whether a site or site pair is selected by the ResolvedSelector. This is now done using the Base.in function, which is more idiomatic than what we had before.

This change is motivated by the fact that, upon introducing indices in selectors, it makes much sense to allow ranges such as hopselector(indices = 1:100 => 101:200), for example. If we were to expand that, checking membership as in 1=>2 in resolved_selector would be very inefficient. Leaving the input form unexpanded and using dispatch is the optimal approach for indices, so we might as well extend that to sublats while we are at it.

Together with this we now have to new functions in the API, sitepositions(h; kw...) (which replaces sites) and siteindices(h; kw...). These return a (lazy) generator, that can be used in comprehensions to iterate over selected site positions and indices. Note that, as per the current Julia design, such generators have no eltype of length defined, so collecting them is not as fast as it could be. Iterating over them, however, is plenty fast.

siteindices also allows to refactor the applyterms! machinery used to build Hamiltonian from models. This PR also includes such refactor. It has the advantage that whatever future extension to selectors that we do will be automatically applied to Hamiltonian building.

So, with this PR we now have, amongst other combinations, the following type of possibilities,

onsite(1, indices = 1:100, region = ...)
hopping(1, indices = (1 => 3, 1:100 .=> 101:200), range = 2)
[ket(1, indices = s) for s in siteindices(h, region = ...)]
parametric(h, @hopping!((t; p) -> p; indices = 30 => 31))

[codecov-commenter]

Codecov Report

Merging #84 into master will increase coverage by 0.26%.
The diff coverage is 87.21%.

@@            Coverage Diff             @@
##           master      #84      +/-   ##
==========================================
+ Coverage   62.74%   63.01%   +0.26%     
==========================================
  Files          16       16              
  Lines        2668     2690      +22     
==========================================
+ Hits         1674     1695      +21     
- Misses        994      995       +1     

Impacted Files	Coverage Δ
src/Quantica.jl	100.00% <ø> (ø)
src/plot_makie.jl	0.00% <0.00%> (ø)
src/plot_vegalite.jl	0.00% <0.00%> (ø)
src/presets.jl	32.07% <ø> (ø)
src/lattice.jl	68.02% <87.50%> (+0.63%)	⬆️
src/model.jl	75.60% <88.46%> (+5.78%)	⬆️
src/hamiltonian.jl	75.03% <90.00%> (-0.60%)	⬇️
src/parametric.jl	84.04% <100.00%> (ø)
src/tools.jl	65.47% <100.00%> (-3.14%)	⬇️
... and 1 more

---

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 bcc2385...d620a32. Read the comment docs.