Improve operator compression

--- old
+++ new
@@ -1,13 +1,17 @@
+**Note**: Relevant for exponentiation of operators, because any moderately complex setup needs to be squeezed first.
+
 #####What and Why#####

 The operator squeezing that was introduced in [#95] has numerous problems. For starters it is both too simple to be useful and too complex to continue working on it.

 A better approach would be to first assume that the user can help us. For example, she may not give us the whole Hamiltonian for compression, but only the potential, which is just a sum of DVR-diagonal operators and constants. Under this assumption, we can go for much more aggressive optimization by just giving up on complex situations. Also, the OOP component approach that I fancied while writing this code is probably overblown here; noone except absolute experts will ever change the order of the modifications.

-The suggested alternative is then:
+The suggested alternative is then the following procedure:

-1. Expand the operator into a sum of products of operators. This should be doable and even reduce the performance in edge cases, but recall that the user may help us.
-2. Try to merge all neighboring commuting operators in the products. The code from [#213] will probably help here.
-3. Try to merge summands that are all diagonal in DVR or so.
+1. Expand the operator into a normal form: a sum of products of elementary operators. This may reduce the performance in some edge cases due to duplication, but recall that we expect reasonable input from the user here.
+2. In each operator product, merge neighboring commuting operators. In general, we do not know about that, so we should go for DVR operators (real/complex, 1D/ND), constants (real/complex), and time-dependent terms that are merged.
+      -  ideally, we would choose here if we combine them into a 1D or ND potential depending on the input, but that is an additional efficiency issue and can be outsourced.
+4. Merge summands that are all diagonal in DVR or so.
+5. One could consider additional steps like combining sums of similar composition, but that may be overkill and should be a separate issue.

 This will not produce a cornucopia that speeds up all operators, but can help with the usual case of potentials made up of a bunch of one-dimensional potentials or products of constants times potentials etc.

--- old
+++ new
@@ -10,8 +10,14 @@

 1. Expand the operator into a normal form: a sum of products of elementary operators. This may reduce the performance in some edge cases due to duplication, but recall that we expect reasonable input from the user here.
 2. In each operator product, merge neighboring commuting operators. In general, we do not know about that, so we should go for DVR operators (real/complex, 1D/ND), constants (real/complex), and time-dependent terms that are merged.
-      -  ideally, we would choose here if we combine them into a 1D or ND potential depending on the input, but that is an additional efficiency issue and can be outsourced.
+       Ideally, we would choose here if we combine them into a 1D or ND potential depending on the input, but that is an additional efficiency issue and can be outsourced.
 4. Merge summands that are all diagonal in DVR or so.
 5. One could consider additional steps like combining sums of similar composition, but that may be overkill and should be a separate issue.

 This will not produce a cornucopia that speeds up all operators, but can help with the usual case of potentials made up of a bunch of one-dimensional potentials or products of constants times potentials etc.
+
+#####Acceptance criteria#####
+
+* The squeezing code is rewritten as a set of functions with the algorithm described here
+* Performance effects are measured where required
+* Update the demos to employ the squeezing where sensible

--- old
+++ new
@@ -21,3 +21,4 @@
 * The squeezing code is rewritten as a set of functions with the algorithm described here
 * Performance effects are measured where required
 * Update the demos to employ the squeezing where sensible
+* Update ticket [#143] depending on the outcome here.

--- old
+++ new
@@ -12,7 +12,7 @@
 2. In each operator product, merge neighboring commuting operators. In general, we do not know about that, so we should go for DVR operators (real/complex, 1D/ND), constants (real/complex), and time-dependent terms that are merged.
        Ideally, we would choose here if we combine them into a 1D or ND potential depending on the input, but that is an additional efficiency issue and can be outsourced.
 4. Merge summands that are all diagonal in DVR or so.
-5. One could consider additional steps like combining sums of similar composition, but that may be overkill and should be a separate issue.
+5. One could consider additional steps like combining sums of similar composition, but that may be overkill and should be a separate issue. See also [#143]

 This will not produce a cornucopia that speeds up all operators, but can help with the usual case of potentials made up of a bunch of one-dimensional potentials or products of constants times potentials etc.

--- old
+++ new
@@ -1,4 +1,6 @@
 **Note**: Relevant for exponentiation of operators, because any moderately complex setup needs to be squeezed first.
+
+Goes well together with [#197]

 #####What and Why#####