P3M: further refactoring

[RudolfWeeber]

Refactoring so far has made P3M much more readable. Many thanks @jngrad

Looking at the code, I think, the folowing things are sitll open:

• Disentangling general FFT info from specifics of the actual implementaiton for 3D ffts
• Related: abstracting away the changed data layout after FFT
• Maybe, we could use more speaking variable names in some places, e.g. replace "sm" and "fft.plan.new_mesh" by sth clearer

Details w.r.t FFT

We currently use a "hand-written" implementation for 3d FFt with MPI. This will be replaced by a library
We should split code/data strutures, that are independent of the specific implementtion.
This is, to my understanding:

• The global and mpi-rank local dimensions of the charge mesh (i.e. the input to the 3d fft)
• the global and mpi-3ank local indices for the charge grid in k-space (i.e., the output of the fft)
• access functions for the k-space mesh (because some FFt implementation, including the one we have now, have a different memory layout after transform. E.g., the ESPResSo implementaiton swaps between col-major and row-major during transofmr)
• functions for forward/backward FFT

Maybe this can be put in a base class, and specific implementations in sub-classes.