For the record

@perturbing We might want to cover the case for empty polynomials in fft_mul, since we get the following fail:

thread 'tests::test_fft_mul_empty_polys' panicked at src/lib.rs:201:5:
Test failed: assertion failed: `(left == right)` 
  left: `[]`, 
 right: `[Scalar(0x0000000000000000000000000000000000000000000000000000000000000000)]`: Failed on case left = empty, right = non-empty with right.len() = 1 at src/lib.rs:209.
minimal failing input: non_empty_vec = [
    Scalar(0x0000000000000000000000000000000000000000000000000000000000000000),
]
	successes: 0
	local rejects: 0
	global rejects: 0

Yeah, sounds good.

It's also a balance between safety and speed. In the code as it is now, I highly favored speed and less complexity.

But we can also make the interface safer, in that we introduce a type for a polynomial and create an interface where polynomials are always normalized and no trailing zero's etc. Then the zero is uniquely the empty list.