MAINT: unify usage of calls to parent classes, closes #1061

[kohr-h]

Getting this out of the way.

Caveat

There are some cases when super() is the wrong choice, most notably with multiple inheritance and "conflicting" methods. Everything is good as long as a certain method only exists once or things stay nicely in order. However, consider the case of ScalingFunctional which I stumbled over while doing this change.

We have class ScalingFunctional(Functional, ScalingOperator), with MRO

[odl.solvers.functional.default_functionals.ScalingFunctional,
 odl.solvers.functional.functional.Functional,
 odl.operator.default_ops.ScalingOperator,
 odl.operator.operator.Operator,
 object]

So far, so good. The __init__ method of ScalingFunctional even hardcodes the __init__ calls to both parent classes, not using super. Everything should be fine, or?

Turns out, no. The crucial part is the common misconception (also on my part) that in an instance method of a class, self always refers to an instance of that class. That's not true. In this case, when Functional.__init__ uses self, then self is an instance of ScalingFunctional. In particular, when using super to resolve the MRO, it is still the one of ScalingFunctional.

Hence, when Functional.__init__ calls super(Functional, self).__init__(...), then the __init__ method that is called is not the one of Operator (the only parent of Functional), but the one of ScalingOperator, because it comes first in the MRO.
We can confirm this by printing self.__class__.mro() in Functional.__init__:

[<class 'odl.solvers.functional.default_functionals.ScalingFunctional'>,
 <class 'odl.solvers.functional.functional.Functional'>,
 <class 'odl.operator.default_ops.ScalingOperator'>,
 <class 'odl.operator.operator.Operator'>,
 <class 'object'>]

Conclusion

We have to be careful with multiple inheritance the MRO contains potentially conflicting methods. As the documentation says, super is intended for collaborative classes, and this situation is not like that.
Sometimes it's hard to tell who will call what. Two ways to mitigate this are:

1. Don't use super in classes that may participate in non-collaborative multiple inheritance. That applies mostly to core classes. It may be hard to know in advance which classes will be affected.
2. Avoid non-collaborative multiple inheritance as far as possible. In particular, try to keep the class hierarchy linear if possible.

[adler-j]

Nicely done, only some very minor stuff to comment on.

[adler-j]

odl.rn(3) * (odl.rn(3) * odl.rn(3))

[adler-j]

odl.rn(3) * (odl.rn(3) * odl.rn(3))

[kohr-h]

Rebased and fixed, merging after CI.