Implement real FFT

[ejmahler]

This isn't ready to merge yet, but it's in a previewable state.

I used the RealFFT crate as a starting point for the new structs, and I was able to make a few optimizations to bring down the overhead by about a third.

Todo:

• Find a paper or something for odd-sized real FFTs
• Implement an AVX version of c2r and r2c
• Clean up unit tests
• Write some integration tests
• Benchmark and write some c2r and r2c butterflies, so that using r2c is always faster than or equal to a normal FFT
• Decide what to do with the planner. Should this stuff go in the current planner? Should I make a new planner that wraps the current one? If we made a new planner, it would make it harder to integrate AVX. But I'm worried about a slippery slope where we bloat the planner struct until it's this giant monolith.

[ejmahler]

cc: #28

[HEnquist]

Very nice! For the first point, I have tried and failed. The only thing I have found is the implementation in fftw, but it's very hard to read. And they don't provide any references (that I have been able to find at least).
When you look under the hood of most other implementations, they turn out to cheat and just use a C2C transform of the same length.

For the planner, I also think adding more and more things in the current planner is risky. But the stuff added in this PR are reasonable, just reusing the existing things and wraps them up as a R2C or C2R. But that simplicity disappears if there are special R2C butterflies.. Probably needs some more thinking.

[micwoj92]

This branch has conflicts that must be resolved

[ejmahler]

Given what I've learned about this since opening the PR (IE that implementing odd R2C essentially requires fully rewriting the FFT stack from the ground up), I don't think I'll ever be doing it this way, so I'm closing this.

If I ever fully implement r2c etc FFTs, it'll be in another crate,