Mean bunch momentum == 0 leads to "nan" position values during transformation

When the bunch is empty or has only newly sampled particles (which happens e.g. during the first timestep when sampling with flattop), the mean velocity is always exactly 0. This has a few effects leading a nan rotation matrix that propagates through the functions until positions are all nan.

Here is the program trace:

1. The loop in ParallelTracker::execute calls computeSpaceChargeFields.
2. Printing Quaternion alignment = ... outputs "( -nan , -nan , -nan , -nan )".
3. The variable is generated with getQuaternion(itsBunch_m->get_pmean(), Vector_t<double, 3>(0, 0, 1)).
4. Inside getQuaternion, we have the line u = normalize(u);, where u is the first argument of the call, so equal to itsBunch_m->get_pmean().
5. normalize calls vec / length, where in for meanP == 0, we get length = 0 \rightarrow this makes u == nan.
6. This propagates through the getQuaternion function and makes alignment equal to nan.
7. This initializes a CoordinateSystemTrafo object with a nan Quaternion instance, from which it gets the nan rotationMatrix_m member.
8. This nan rotation matrix is copied to a Kokkos::View that is used to transform bunch_m->R, resulting in only nan position values.
9. Then, the rotation itself is performed like this: Rview(j) = Rot(i,j) * x(i);. This seems to be wrong, since Rview is a Kokkos::View of ippl::Vector elements, it would need to be something like Rview[particles_index](j) = Rot(i,j) * x(i);, however the index i is used twice. Once in the Kokkos::parallel_for and once in the loop over dimensions inside the kernel.
10. Finally, as soon as there is any sort of overallocation, ippl::getRangePolicy iterates in my opinion over ALL elements of the view, not over all initialized elements of the container. This is because view.size() inside getRangePolicy returns the size of the view, not the particle container.
11. Something similar happens to the origin after calling beamToReferenceCSTrafo.inverted();. More specific: the issue arises when CoordinateSystemTrafo::invert() rotates the origin on a nan orientation vector.

So what is the underlying issue?

The issue seems to four-fold:

1. The Quaternion class returns nan, might need to check for 0 length.
2. Rview is indexed in the wrong way (and also i is used twice as a variable).
3. The transformation kernel iterates over ALL "particle memory", not just the allocated particles in the container (however, this should not change values itself).
4. After inverting the beamToReferenceCSTrafo, the origin evaluates to nan.