ESPResSo 4.0.1 released

This release provides a number of corrections for Espresso 4.0.
We recommend that this release be used for all production simulations.
The interface has not been changed between Espresso 4.0 and 4.0.1
However, some bugs were discovered which can affect simulation results.
Below, please find the list of changes. The numbers in brackets refer to
ticket numbers on http://github.com/espressomd/espresso.

Physics related corrections:

The GPU lattice Boltzmann method produced incorrect results when EXTERNAL_FORCES was not declared in myconfig.hpp. This issue was present since around June 2018 (#2241)

The temperature fluctuations for the GPU lattice Boltzmann implementation were larger than the ones for the Cpu lattice Boltzmann implementation. The cause was likely weak or incorrect random number generation. It is not clear since when this issue existed. It has been resolved by using library code for a counter-based random number generator (Philox) rather than the existing custom code.

Particles which were moved with the configuration changing moves (MC) implemented in the reaction ensemble module did not get assigned a random velocity. This was not a problem if you were looking at observables which do not depend on velocity.

Particles which were created in the Reaction Ensemble module were assigned a random velocity which was not distributed according to the Maxwell-Boltzmann distribution. This was not a problem if you were looking at observables which do not depend on velocity. If you looked at velocity dependent observables but used a thermostat for thermalization before taking a sample you are also fine. (#2377).

Under some conditions, the torque on self-propelled particles in a lattice-Boltzmann fluid was incorrect due to a sign error in the ENGINE feature. This was the case since the introduction of the feature (#2383)

The SimplePore shape was incorrect (#2379)

The parameters passed from Python to some features were narrowed to single precision. I.e., the values used were only accurate up to the 7th-8th significant digit. Further calculations with those values still were done using double precision. Classes backed by the script interface were affected. This includes
shapes, LB boundaries, pair criteria and the collision detection. This issue was likely present since the introduction of Python support for the relevant features. (#2379)

Forces on LB boundaries retrieved via the LbBoundary.get_force() method in a Python script were incorrect for the CPU LB implementation. The GPU implementation was not affected. It is not clear, when the issue was introduced. (#2366)