TupleOp refactoring for improved speed

Fixes #34 (closed)

This should be entirely transparent to the user (and bring a significant speed improvement in the python code - especially with automatic systematics), so please check for regressions, otherwise I would merge this relatively soon - I will rebase !36 (merged) (and !26 (closed)) on top of this.

A bit more detail (to be included in a "hacking guide" at some point): the main change is that "expressions" (TupleOp trees) are explicitly assumed to be immutable after construction, except in a few very special cases (e.g. the systematics code makes a clone and modifies an attribute).

The implementation takes advantage of this by caching a hash based on the value, such that dictionary (definition cache) lookup and (in)equality comparisons are very fast in almost all cases (whereas previously they would trigger a recursive function call over all nodes in the expression in all cases). Generally, a few more things are calculated when creating a (sub)expression, rather than on the fly when needed, and the complexity of range-based operation's constructors was moved to factory methods (such that cloning is also trivial and cheap) - this also improved the consistency of their interfaces, and made it easy to remove the collection proxy classes from the expression trees (which makes the expression tree smaller, and simplifies the collection proxies - now there is only ever one proxy wrapping a complete expression, as originally intended). Whether a subexpression could be calculated and cached (i.e. it does not contain free loop counters) is now checked at creation time instead of on the fly (and some flaws of the logic to do this are fixed now).