Rethink Kernel loop in v4

[erikvansebille]

Parcels v3 introduced a revamped Kernel-loop for vectorial/commutable summing (see tutorial). However, it's a bit clunky because

1. It requires a copy of the particle position (lon_nextloop, lat_nextloop, etc), straining memory
2. The final position of the particle is by default not written
3. Particle position (lon, lat, depth) is treated differently from other Particle variables
4. The API may be confusing to users: why do they have to update particle_dlon rather than particle.lon?

Hence, it may be good to revisit the implementation of the Kernel loop in v4, keeping the advantages like vectorial summing but avoiding the downsides listed above

[erikvansebille]

One approach to take is to somehow implement a 'caching' feature on the particle._setattr__, so that the value of e.g. particle.lon is not updated until the end of the kernel loop. Not sure though how this would work. Ideas?

[erikvansebille]

#2123 (comment) could be a way to implemented this (to be tested)