Fix velocity assignment in CubicGridGenerator (and others)

[HomesGH]

Description

As described in issue #376, the CubicGridGenerator uses the initCubicGrid method which uses the getRandomVelocity method.
The latter method can only handle particles with mass=1 correctly. This is fixed with the present PR by using the EqualVelocityAssigner to get the random initial velocities.

In addition, the CubicGridGenerator removes the overall drift, which is very beneficial. Unfortunately, this is not done properly as the velocities need to be scaled afterwards again to match the desired temperature. This was also fixed in the present PR.

Resolved Issues

• fixes Wrong temperature assigned in CubicGridGenerator #376

How Has This Been Tested?

• example DropletCoalescence/liq/config_1_generateLiq.xml was run and the initial temperatures where checked. Everthing looks good now and the initial temperatures are now the target temperatures. Without the rescaling, they would be too low and without considering the mass, the temperatures would be completely off (explosion)

Further improvements (not part of the present PR)

In the future, it would be nice

• to add a mechanism which ensures that the desired density is met, e.g. by deleting particles. Currently, there is no generator that just creates a simulation with a given density and temperature (like in ms2).
• to add the possibility to select the velocity assigner to be used, see comment below.
• to clean up the class, e.g. get rid of "Internal" in names and move initCubicGrid from the particle container to the generator/helper class.

[amartyads]

Thanks for looking into this bug, it's been a pain for a very long time! I can review in a few days, but a few initial thoughts:

1. Having this GridGenerator in the io folder along with a bunch of output plugins is very confusing imo, especially with a separate generators folder, maybe we should have separate input and output folders? In a different PR?
2. If we want to use velocity assigners, maybe it's better to use the approach in ObjectGenerator.cpp, and read in the xml tag <velocityAssigner>, so that we can use MaxwellVelocityAssigner, as well as the random seed features, instead of using only EqualVelocityAssigner. We can create the velocityAssigner object in CubicGridGenerator and pass it to IOHelpers.

[HomesGH]

Thanks for looking into this bug, it's been a pain for a very long time! I can review in a few days, but a few initial thoughts:

1. Having this GridGenerator in the `io` folder along with a bunch of output plugins is very confusing imo, especially with a separate `generators` folder, maybe we should have separate `input` and `output` folders? In a different PR?

2. If we want to use velocity assigners, maybe it's better to use the approach in `ObjectGenerator.cpp`, and read in the xml tag `<velocityAssigner>`, so that we can use `MaxwellVelocityAssigner`, as well as the random seed features, instead of using only `EqualVelocityAssigner`. We can create the `velocityAssigner` object in `CubicGridGenerator` and pass it to `IOHelpers`.

Thank you for your review!

1. Yes, this definitely needs a clean-up! There is also still the "Internal" in the file name and it uses a method of the particle container to create the grid, which should be moved to the generator itself in my opinion. However, this might be done in another PR.
2. That's a good idea! But for now, I just want to make it work (somehow) so that I can continue with the other PRs, e.g. the validation (CI) which currently fails due to the one example with a bad grid setup. Similar to 1., I would prefer doing this in another PR.
   I have added those two points to the above description as possible improvements in the future.

[cniethammer]

I am not super deep into this part of the code and just had the chance for a very rough look.
Overall this looks good to me. I like that you reused and re-checked my code for the velocity assignement from the utils generator library.