Simplify P3M C++ API

[jngrad]

Fixes #4962
Partial fix for #4963

Description of changes:

• disentangle FFTBackend methods: one per FFT transform operation, one per halo communication operation
• make the floating-point type and CPU/GPU architecture template parameters of P3M classes
• add support for P3M CPU and dipolar P3M CPU in single-precision mode

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[RudolfWeeber]

Offline discussion:

• we merge this PR onw.
• Next step is to change the data ownership. The actual meshes (rs_mesh, ks_mesh) should be owned by the solvers. ks_mesh is only needed by the dipolar p3m
• The forward and backward ffts in FFTBackend then take the meshs to transform as arguments
• The halo gather/scatter funciotns can then also be moved out of the FT Backend. They would be called by the actual solvers before the forward and after the backwards transforms, respectively
• The only link between the halo comm code and the fft is that they share the free functions to pack/unpack bllocks. These can be moved out of the fft and be used both, by the legacy fft implementaoitn and the halo communicaoitn (send_mesh)
• The main challange in all this is to hide implementatoin specific data types, e.g., fft_vector or some future Kokkos data type, fro mclients, especially the script interface.