Add a zero_instance method to avoid casting math operations

[philippeitis]

Returning a ZeroPolynomial could be problematic, as you might expect that the following would work:

p = Polynomial(1, 2, 3) * Polynomial(0)
p.a = 5
>>> AttributeError: ...

But it does not, as a ZeroPolynomial is returned and p.a can not be set. Instead, we should define a mutable version of a zero_instance that does not restrict behaviour.

An issue with this would be when we might want to modify a Trinomial / Binomial / other class that enforces restrictions on degree behaviour - these don't really support a zero_instance, as there is no guarantee that they'll become valid class instances - so this change would mostly apply for the Polynomial & Monomial classes.

[yalishanda42]

Adding that zero_instance is really needed, people would really want the class of the object to not change when performing algebraic operations such as the one you mentioned.

Trinomial / Binomial / other class that enforces restrictions on degree behaviour - these don't really support a zero_instance, as there is no guarantee that they'll become valid class instances ...

I think this should be handled as a separate issue. Solving it might be forbidding the user to change the degree of the LinearBinomial, QuadraticTrinomial, etc. An idea I have for that is creating a ConstantDegreePolynomial which raises an exception of one performs an operation which changes the degree of the polynomial and making the previous classes I mentioned subclass from it. As for the plain Binomial, Trinomial, etc. (and maybe even Monomial) a similar class such as ConstantTermCountPolynomial might do the trick.
I guess I will create a separate issue for that problem.

#33 seems to attempt fixing the zero_instance issue here, I guess we can close it whenever the PR is merged.