Implement simple numpy.fft-like interface

[egpbos]

We want to implement a very simple FFT interface, mimicking the numpy.fft default behavior. This means that we want the following matrix of functions:

• fft for standard complex to complex transforms, rfft for real FFTs (real signal) and hfft for Hermitian FFTs (real Fourier spectrum);
• an inverse for each operation, prepending an i, e.g. ifft;
• a 1D (default), 2D, 3D and nD version of each function, the latter three indicated by appending 2, 3 or n, e.g. irfft3.

That's a total of 24 functions.

Additionally, we want to support single, double and long double precision arrays. This can be implemented through template specializations. The total amount of implemented functions would then be 72.

Also part of this interface would be broadcasting over multiple array dimensions, if the dimension of the function is smaller than that of the array itself; see #4.

[egpbos]

One issue to decide on is how to deal with FFTWs behavior of destroying input for complex to real transforms (see FFTW_DESTROY_INPUT).

For multi-dimensional transforms it's not possible to use FFTW_PRESERVE_INPUT, so it might be more consistent to set it to FFTW_DESTROY_INPUT for 1D transforms as well.

However, this will break numpy.fft compatibility. It may be good to print a warning message to make this clear.

[egpbos]

FFTW offers specialized functions for ranks 1, 2 and 3 and a general function for n-dimensional transforms. However, we should benchmark whether the 1-3 dimensional special functions are actually faster than the n-dimensional one. If not, we can just use one implementation function for all ranks, with simple wrappers for the 1, 2 and 3 dimensional cases. This would reduce the number of implemented functions from 72 to 18, plus 54 simple wrapper functions. See issue #13.

[egpbos]

Edited top comment, adding multiple precision functions.

[egpbos]

The templates from commit 133f1be should probably be inline.

[egpbos]

Regarding the destroy input comment above: I opted to go for destructive functions. This should be added to the documentation (#12).