Reconsider use of particle.lon, particle.dlon and particle.lon_nextloop

[erikvansebille]

With the new Kernel loop in #2123 and the refactoring of ParticleFile into v4 in #2142, it is now time to reconsider the implementation of the two Variables particle.lon and particle.dlon (and similar for lat and z and for time we also need a third Variable particle.time_nextloop).

It would be nice to drop at least one of the Variables because of memory footprint and code simplifications. However, I don't (yet) see a path how to do this.

There are a few core considerations:

1. The starting locations (so at time=0) of particles need to be written to output
2. The result of kernel samplings needs to be independent of the order of the kernels, so particle positions shouldn't be updated until the end of the Kernel loop.
3. The spacetime location at which a field is sampled needs to be in agreement with the spacetime location in the output file.

Furthermore, there is also room for improvement:

4. Ideally, the final location (so at time=runtime) is also written to output (this is not the case in v3)
5. Ideally, custom variables are treated the same way as lon, lat, z and time (this is not the case in v3)

This tracking issue can explore ideas how to implement these ideas

[Update: particle.lon_nextloop has been removed in #2212; although particle.time_nextloop is still needed (see #2213)]

[erikvansebille]

Pinging @reint-fischer for feedback

[erikvansebille]

In #2333, we have gotten rid of time_nextloop too. As an added bonus, the final location is also written by default (point 4 above)

[erikvansebille]

Fixed in #2333