New Interpolator Backend

[dkumor]

Currently, the interpolators available don't really allow truly powerful analysis.

The notes here are copied from personal internal brainstorming comments - this issue will be updated with more clarity once the time to work on it comes.

    - [ ] Closest within - if there is missing data, don't use the closest datapoint that is actually far away, but rather closest within given time range. Maybe add arg to closest, ie `closest(60*15)` would give null if closest datapoint not in past 15 minutes.
    - [ ] Midline Transform - a transform interpolator that takes all datapoints in the midline between two points… IE closest, except with a transform of all datapoints, and optionally with range.

Maybe make closest interpolator accept both a transform pipe, and a possible range, so.…
- `matched` - identical timestamp, same as `closest(0,null,0)`
- `closest` - same as now
- `closest(15*60)` 15 minute radius on either side
- `closest(15*60,null,10*60)` asymmetric radius, single closest point
- `closest(15*60,mean)` mean of all datapoints in a 15 minute radius
- `closest(15*60,mean,10*60)` mean of all datapoints starting 15 minutes before, and ending 15 minutes after. Negative numbers are also accepted here, to allow offset transforms, as well as Inf to represent forever (if null transform)
- `closest(15*60,mean,10*60,'exclusive')` - no overlap in datapoints. Possibilities: `overlap` and `exclusive`
- `before` same as now - single datapoint before, no limit. Equivalent to `closest()`
- `before(15*60)` within 15 minutes
- `before(15*60,mean)` same as `closest(15*60,mean,0)`
- `before(0,mean)` all datapoints from previous
- Same with after…
- If I add `isum`, `imean` trasnforms, OR allow choosing transforms that enforce "i" when required, this would let things work well!
- Also want `during` transform for datapoints with duration, and want handling of durations even with closest - closest to start, end, or middle?

The closest interpolator seems like it is actually incredibly powerful, especially if combined with tshift… do we even need anything else?
Would like some type of gaussian thing in the future, so yes, we need the `closest` interpolator.
BUT now do we actually need it to have args and parsing, or can we make its args an object that is sent in as interpolator?

I think having it an object is the right way to approach - it fits the structure