Moving the time interpolation down to within _Interpolator functions

[erikvansebille]

Parcels previously would run an interpolation on time index ti and one on ti+1, and then at the end linearly interpolate the results.

In this PR, we change that to do the time-interpolation closer to the InterpolationContext. We need to discuss whether this is the right place now, or whether we want to push it even into the interpolators themselves. The latter would open possible support also non-linear time-interpolation

Hence, this is more a proof of concept than a full-fledged PR to be merged...

• Chose the correct base branch (main for v3 changes, v4-dev for v4 changes)

[VeckoTheGecko]

I think it may be a good idea with these interpolation functions (where all the arguments are numeric) to force keyword only arguments. i.e.,

- def x(a, b, c):
+ def x(*, a, b, c):

>>> def x(*, a, b, c): pass
... 
>>> x(1,2,3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: x() takes 0 positional arguments but 3 were given

This forces users to use keyword arguments, preventing errors like accidentally switching yi, and xi in the function call which can be easily missed.

_get_data_temporalinterp(ti=ti, yi=yi + j, xi=xi + i)

It can become a bit repetitive when calling them, but I think it's worth it for the added safety? Thoughts @erikvansebille?

[VeckoTheGecko]

Could we rename to should_calculate_next_ti to be clearer?

And refactor to

tau_is_significant = tau > np.finfo(float).eps
return tau_is_significant and ti < tdim - 1

[VeckoTheGecko]

@erikvansebille I was just thinking wouldn't np.isequal(tau, 0.0) have the save effect?

[erikvansebille]

Sure, but we would then need to do something like tau_is_significant = not np.isequal(tau, 0.0); would that be more readable, with the not?

[VeckoTheGecko]

I think that sounds good