Fix a serious bug in `imperative_operator` (#819) introduced by PR #686

[krivenko]

PR #686 changed the order in which fundamental_operator_set stores index combinations. Before that PR, mutual order of two index combinations was dictated by the result of operator<(), which had been consistent with the way many_body_operator orders canonical operators within a monomial. Now the order of the index combinations and - consequently - of single particle bits forming a Fock state is arbitrary. When computing fermionic sign prefactor, the constructor of imperative_operator relied on ordering of the bits being consistent with the ordering of the monomial. PR #686 broke that assumption, which resulted in a dangerous and hard-to-find bug -- sign of some matrix elements can be erroneously flipped.

This PR fixes the issue by sorting monomials in imperative_operator's constructor and revealing a possible sign change due to a permutation of canonical operators caused by fops.

With this fix, the Python script from #819 gives the following output.

[0. 0. 3.] [0. 0. 3.]
[0. 2.] [0. 2.]
[0. 2.] [0. 2.]
[0. 2.] [0. 2.]
[0. 2.] [0. 2.]
[0. 2.] [0. 0. 3.]
[0. 0. 3.] [0. 2.]
[0. 2.] [0. 2.]
[0. 2.] [0. 2.]
[0. 0. 3.] [0. 2.]
[0. 2.] [0. 0. 3.]
[0. 0. 3.] [0. 0. 3.]
[0. 2.] [0. 2.]
[0. 2.] [0. 2.]
[0. 2.] [0. 2.]
[0. 2.] [0. 2.]
[1.] [1.]
[1.] [1.]
[1.] [1.]
...
[1.] [1.]

Despite the fact the base branch is set to 3.0.x here, I would greatly appreciate having the fix on 2.2.x as well.

[Wentzell]

Thank you @krivenko for this fix!

[Wentzell]

This was merged into 2.2.x in babab7d8 and into unstable in fee87d74