Implement high performance interface

[egpbos]

The simple numpy-style interface (#6) will by default hide some of FFTW's features, opting for simplicity and default settings for decent performance. We will also implement a high performance interface to access functions like

• Choosing FFTW_MEASURE, FFTW_PATIENT, or FFTW_EXHAUSTIVE planner flags (instead of the default FFTW_ESTIMATE);
• Reusing plans and wisdom;
• Using fftw_malloc to guarantee optimal memory alignment;
• FFTW_PRESERVE_INPUT vs FFTW_DESTROY_INPUT, the latter can sometimes be faster.

[egpbos]

When implementing this, keep in mind that many FFTW functions destroy input and/or output arrays! E.g. FFTW_MEASURE destroys both during measurement, c2r functions always destroy input by default (unless for 1D transforms if you pass FFTW_PRESERVE_INPUT), etc. More info: http://www.fftw.org/fftw3_doc/Complex-One_002dDimensional-DFTs.html#Complex-One_002dDimensional-DFTs

[ghost]

do you plan to implement multi-threaded FFTW in the future?

[egpbos]

@CUBER12 yes, in time, for sure. I'm using multithreaded FFTW in barcode. My plan is to migrate that code to xtensor and use xtensor-fftw for FFTW. At that point, I will have to optimize xtensor-fftw. However, in the mean time, if you already need it now, please feel free to make a PR for it. FFTW is not difficult to use in multithreaded mode. I just didn't think about how to integrate that into xtensor-fftw nicely. If you have ideas on that, I'd also love to hear them. Preferably start a separate issue for that.