Predictor-corrector loop to compute transverse magnetic fields

[SeverinDiederichs]

This PR resolves #105 .

So far, the transverse magnet fields were calculated via
Laplacian(Bx) = -mu_0* d_y(jz)
Laplacian(By) = mu_0d_x(jz)
However, they should be calculated via
Laplacian(Bx) = mu_0(- d_y(jz) + d_z(jy) )
Laplacian(By) = mu_0*( d_x(jz) - d_z(jx) )

To calculate the longitudinal derivative of jx and jy, a predictor-corrector loop is required, which works as follows:

1. an initial Bx and By value is guessed via InitialBfieldGuess.
   The guess is calculated by B_guess = (1+c)B_previous_slice -cB_one_before_previous_slice
2. Using these Bx and By values, the plasma particles are advanced to the next slice and deposit their current there.
3. With that current in the next slice, d_z(jy) and d_z(jx) and therefore Bx and By can be calculated. The longitudinal derivative was implemented in a similar fashion as the transverse derivative.
4. By mixing the calculated Bx and By with the previous guess, a new Bx and By is calculated.
   The mixing is done via Bx = aBx + (1-a)( cBx_iter + dBx_prev_iter). The mixing coefficients a, c, d are hard-coded at the moment.
5. Bx and By are used to update the force terms on the plasma particles
6. 2.-5. are repeated for a fixed number of iterations. Later, this should be adaptive, an error between the B field iterations should be calculated, allowing for a convergence criterion instead of a fixed number of iterations.

For this PR, the current deposition had to be updated, because it was not capable of depositing a current to the next slice correctly before.
All benchmarks needed to be reset, because all field values differ (even for the beam in vacuum, as Bx and By are differently calculated).

Below some results:
Linear regime:

The field does not perfectly agree with the HiPACE-C solution, because the Dirichlet boundary conditions are missing (see #130). This can be seen in the Ez_zx snapshot: the field should be 0 at the boundaries of the box.
Quasi-linear regime:

It should be noted that the introduction of the predictor-corrector loop makes the code unstable.
A badly chosen input script will result in non-physical fields, leading to self-enhanced currents, causing segmentation fault crashes.

• Small enough (< few 100s of lines), otherwise it should probably be split into smaller PRs
• Tested (describe the tests in the PR description)
• Runs on GPU (basic: the code compiles and run well with the new module)
• Contains an automated test (checksum and/or comparison with theory)
• Documented: all elements (classes and their members, functions, namespaces, etc.) are documented
• Constified (All that can be const is const)
• Code is clean (no unwanted comments, )
• Style and code conventions are respected at the bottom of https://github.com/Hi-PACE/hipace
• Proper label and GitHub project, if applicable

[MaxThevenet]

Great, thanks for this big PR! Here are a few general comments:

• Could you instrument the code (i.e., add BL_PROFILE in main functions)?
• Since this predictor-corrector loop is particularly error-prone, could you describe, for each function used in there, which exact fields it updates?
• For cleanliness, could you update benchmarks in a separate commit, and use git commit -m "reset benchmark because ..." --author="Tools <hipace.tools@desy.de>"

[MaxThevenet]

Yay!