Fix the Mul ordering issue

Before:
```
$ ./expand2 
Expanding: ((y + x + z + w)^15 + w)*(y + x + z + w)^15
1574ms
number of terms: 6272
```
After e1b3d8b36b4b9c410910577e1318a7f206a2ab49:
```
$ ./expand2 
Expanding: ((y + x + z + w)^15 + w)*(y + x + z + w)^15
1658ms
number of terms: 6272
```

At the moment, it is 5% slower. After the commit 84ea2379541860d0a0d4fb3d1af94b1c783bcd97:
```
$ ./expand2 
Expanding: ((y + x + z + w)^15 + w)*(y + x + z + w)^15
1580ms
number of terms: 6272
```
After commit 1c80e7776f507ea3b83f93362f54df1f560ce564:
```
$ ./expand2
Expanding: ((y + x + z + w)^15 + w)*(y + x + z + w)^15
1530ms
number of terms: 6272
```

Compared to #66, it is clear that `__eq__()` is faster than computing hashes. We need to improve hash() computation.

TODO:

* [ ] Speedup hash calculation, and cache the hashes
* [x] Bring the speed penalty introduced by this fix down
* [x] Finish the ordering implementation for the case when `x != y`, but `hash(x) == hash(y)`
* [x] Implement `int compare(const Basic &b)` methods, that do not use hashes. In `RCPBasicKeyLess`, compare hashes first, if they are equal, only then run `compare`.

Conclusion: At this point, the PR does not introduce a slowdown (in fact it introduces 2.3% speedup), and it fixes an important bug.