[ITensors] [QN] Improve `siteinds` QN conservation interface

[mtfishman]

Right now, for more complicated site types, there is a bit of an explosion of keyword arguments for choosing what QNs get conserved. Here is a proposal for an improved interface:

siteinds("Electron", conserve_qns = ("Sz", "Nf", "NfParity"))

instead of the current:

siteinds("Electron", conserve_sz = true, conserve_nf = true, conserve_nfparity = true)

Setting conserve_qns = true would select a preset choice that we consider to be the most common combination.

Additionally, if someone wants custom names for the QNs, we could have a syntax like the following:

siteinds("Electron", conserve_qns = ("Sz" => "SzA", "Nf" => "NfA", "NfParity" => "NfPA))

which is useful if there are lattices with mixed site types.

Finally, it would be nice to think about a system for providing custom QNs to an existing site type. An example is adding momentum conservation to the Electron site type. This could be done with a QNType, analogous to the SiteType, where a user overloads a function like:

qn(::SiteType"Electron", ::QNType"Sz") = [("Sz", 0) => 1, ("Sz",+1) => 1, ("Sz",-1) => 1, ("Sz", 0) => 1]

This system could also make the implementation of the space function easier, where the specified conserved QNs are looped over and appended to the space (instead of the current system with many if-statements). We would need nice functions for this which are fast and deal with the case of mismatched blocks.

[emstoudenmire]

I definitely support this improvement. The "intersection of booleans" approach I've done so far is starting to really show its limitations I agree. One symptom is that users have been confused about how to obtain certain QN combinations, and rightly so.

My main comment (which I think you touched on at the end) is that internally we could use some helper functions to process these tuples of QN names so that the implementation is clean enough and uniform across the different built-in site types.

The idea of providing qn overloads is creative and really interesting. I think it's tentatively a good idea, but let's prototype it at some point and see how the resulting code looks. My one concern there is that the code flow of functions like op or space could become too convoluted, where a user reading it for the first or second time could just get lost in the complexity or find it too opaque (since the code is calling out to so many other functions whose purpose might not be obvious unless explained really well). The constrasting approach would be to say something like "if you need something like the "Electron" site type but with very different QNs, please copy the electron.jl file and change the name to something else and then customize the space function". So that's the other approach I see as the competitor initially.

[mtfishman]

Definitely agreed that the qn overload adds extra complexity to the design and we should consider if it is worth it (and like you say, for now users can just copy the definition and extend it themselves).