Add along-trajectory values of 'other' fields to netcdf output

[oceanparcels]

Add along-trajectory values of 'other' fields to netcdf output

[Jacketless]

I'll take a look into this over the next few days- I think it would be a good way for me to get into the particle class and resulting netcdf files. I'm likely to be working on this kind of functionality a lot in parcels I imagine.

[mlange05]

I think automatically sampling and outputting each additional field on a grid is too much defaulting, since it will make it very easy to "accidentally blow-up" the output file and adds a lot of invisible "behind the curtain" behaviour. It also requires us to automatically insert particle.var = grid.Var[time, particle.lon, particle.lat] into at least one kernel executed per output timestep, which will be very awkward to do right when executing kernel chains.

Instead I would propose to have a list of "output variables" on user-defined Particle classes that defaults to all user_vars. This way output gets triggered by adding variable var to a kernel class, but users have to insert the sampling call themselves. It also gives users control over the output file, allowing them to "slim it down" if they wish to do so. I would also note that ultimately we probably want to derive user_vars automatically by inspecting the kernel objects, meaning that adding the sampling call will automatically trigger output, but that is only a syntactic shortcut to be added later.

[erikvansebille]

Fixed with particle-sampling PR