Add generic implementation for FFTnum

[prehner]

This PR changes the supertraits of FFTnum from Signed to Num + Neg<Output = Self>.
Signed is overly restrictive and not used within the crate beyond Neg.

The generic impl:

impl<T> FFTnum for T where T: Copy + FromPrimitive + Num + Neg<Output = Self> + Sync + Send + 'static {}

enables usage of different structs that are defined outside the crate.

These changes are needed for our use case: We use own numeric types (HyperDual numbers, see num-hyperdual) to calculate derivatives of convolution integrals.

[ejmahler]

In what way is Signed overly-restrictive? Are you straight up unable to implement that trait? Or do its methods just not make sense for your struct?

This is a breaking change - if someone depending on RustFFT wrote a function that was generic over FFTnum, and called abs() on an instance of a FFTnum, their code would no longer compile.

I suspect there are workarounds though, like making a new trait, making the FFT trait generic over that new trait, then making FFTnum require that new trait + Signed. What do you think?

[prehner]

We discussed this topic and decided that it is indeed not unreasonable to implement the Signed trait for dual numbers. (They are not differentiable at x=0, but the same is true for other functions like recip which are implemented).

Therefore it is only the generic implementation that is required to use this crate with dual numbers. This is an enormous advantage over any FFT implementation with external bindings, so thank you at this point for the work you put in this nice crate.

[ejmahler]

Superseded by #12, mainly so I could omit the formatting changes

[ejmahler]

@prehner To let you know, I just release v4.1 on crates.io which has this change.