- contributes to #50,
- depends on #53 and builds on it,
- due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`,
- I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned,
- hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>`
- the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose
- and that, even though I don't think it's used.

eliminate a few redundant references

avoid return when it cant be early (in a simple if-else)

See https://rust-lang.github.io/rust-clippy/master/#explicit_into_iter_loop

* Update API of EvaluationDomain

* Update gm17 to use new API

* Move fft infrastructure to its own crate

* Fix gm17 to work with ff-fft

* Refactor polynomial infrastructure

* Change .travis-yml to not compile in release and to not run DPC tests