Implementation of CPU multi-threading

[MKirchen]

• Reworked particle methods (to not use weights function anymore)
• Introduced prange (parallel execution on multiple threads) for most important particle methods (push, deposition, gathering)
• Refactored "particles" folder and code. New cleaner structure.
• Removed "linear_non_atomic" GPU deposition method. Although this one might be faster in some cases, we don't use it anymore by default. Moreover, the atomic_add version is much more cleaner and therefore, we should only stick to this one. (Also, in a test on the Tesla P100 both deposition schemes had the same speed)

ToDo:

• Adapt imports in tests so that they do not fail anymore
• implement cubic shape order deposition methods (just need to copy/paste and adapt from GPU version) Needed to fix the cubic gathering methods by using while index_z < 4 instead of a for loop Should ask numba developers, as this should be a bug
• implement prange for field methods ( use prange and not vectorize as I think prange is faster - use prange over both axis ) - Question to @RemiLehe : Should we keep the old methods and adapt to the structure of the particle folder or use prange as default?
• Maybe: Write our own reduction function to replace np.sum() in deposit - or we wait until numba prange supports the axis argument in np.sum() (this is planned to be implemented) Merged, but: Is it possible to also prange over Nr?
• Maybe: Move allocation of global deposition arrays to init function such that we don't have to reallocate each time deposit is called. (we should have enough memory available with CPU, so that might be good to do) _We would need to pass Nz, Nr to the Particles object.
• @RemiLehe Is there threading with blas() for CPU? (or do we just use array multiplication with numba? I forgot how its implemented for CPU.)
• Nice to have: Adapt GPU and CPU gather function/kernel to match the structure of the cubic gathering function (maybe we get same performance but with a cleaner code). Moreover, check if by now lists are maybe supported with CUDA kernels. Then we could get rid of cuda.local.array(). Or maybe we directly write iz/ir/Sz/Sr to the registers.
• Check availability of prange: Similar to cuda_installed we should check the availability of prange

[RemiLehe]

Just a random thought: wouldn't the operation below be faster if we initialize rho_m0_global with a different shape (i.e. such that we do rho_m0_global[tx,:,:] = rho_m0_thread and thus the copying is contiguous in memory).

I agree that then the reduction operation is then maybe not as fast, but we could also write a numba reduction function that uses prange (with parallelization across the z index for instance).

[RemiLehe]

Regarding the threading for the BLAS operation on CPU: it is already used by default in the current dev branch. I think it is controlled by the environment variable MKL_NUM_THREADS.

[MKirchen]

good catch! thx

[RemiLehe]

@MKirchen Would you be okay with using an array for tx_chunks instead of a list?
I am worried that a list may be cumbersome for numa, since numba then has to check the type of every single element of the list, each time it is calling a jitted function (as opposed to just once for an array).

[RemiLehe]

This is a fantastic pull request!! Thank you very much! 🎉 ✨ ✨