Removing Trotter pitfalls

[TysonRayJones]

No description provided.

[TysonRayJones]

Not yet implemented: changing Trotter functions to consult & permute an index list

[TysonRayJones]

@vaferreiQMT @otbrown Any objections to this? The parts worthy of explicit consideration are:

• renamed permutePaulis to permuteTerms, since it's not the "Paulis" that are permuted; it is entire terms (Pauli strings and their corresponding coefficients).
• removed unguarded allocs from pauli reordering which removes util_getInversePermutation and paulis_applyPermutationToTerms, doing everything directly inside paulis_sortTermsViaComparator. This is because the former approach caused non-obvious temporary copies of the sum.
• I kept sortPauliStrSumLexicographic() and sortPauliStrSumMagnitude(), though their "obvious" utility has now been removed (which was restoring a concrete ordering after random permutation in the Trotter functions). I think sortPauliStrSumMagnitude() remains useful however, since useful for significance sampling.
• rand_permutePauliStrSum() was removed since it is now no longer called anywhere. In theory, we can retain it and expose a new randomizePauliStrSumOrder() API function for the user, but I shied from this since it doesn't seem to have much utility: randomisation only benefits the Trotter functions, which accept permuteTerms. I suppose it would be just as useful as sortPauliStrSumLexicographic(); as an alternative to sortPauliStrSumMagnitude() for testing the relative benefits of sorting by magnitude. Any strong thoughts??

[vaferreiQMT]

All looks reasonable to me. I also think that sortPauliStrSumMagnitude() is worth keeping, but I don't mind getting rid of rand_permutePauliStrSum() since I agree that it likely wouldn't be of particular use for most users beyond comparing the impact of different sorting methods.