Implement muiltidimensional FFTs

[ejmahler]

2d FFTs, 3d FFTs, n-d FFTs, now a first class feature of rustFFT. Constructed through the planner, stored as an Arc, executed through an interface almost exactly the same as the current single-dimension FFT trait.

Right now there's only one algorithm: Transpose once per dimension, execute FFTs contiguously. But I did it through the planner because I can imagine doing something like, if one of the non-contiguous FFTs is the size of a butterfly, then the various SIMD backends could switch to a different algorithm that leaves it strided and executes parallel column FFTs. Or maybe it'll turn out that leaving it strided and copying to a local buffer for execution and immediately back is faster for some sizes, so we have 2 algorithms, one strided and one that tranposes.

This doesn't do any of that yet but it leaves the door open. I haven't done any benchmarking yet, and I'd like to implement a strided algorithm and compare the two before I merge this, and maybe do a comparison with fftw

I'd like to hear feedback anyone has on API. naming, etc, as well as just a normal review of the code.

[ejmahler]

I thought for a little while that FftNd should just inherit from Fft because the APIs are identical, but I realized that they're the same syntactically, but are different semantically. If you have an object of type dyn Fft<T> you should be able to trust that calling process() will compute a FFT, and that wouldn't be true if FftNd inherited from Fft, and you obtained a FftNd and coerced it to a Fft.