More common ground for "rimeX.preproc.digitize" and "rimeX.preproc.quantilemaps"

[perrette]

Right now rime-run-timeseries --vectorized passes through rimeX.emulator.recombine_gmt_vectorized.
This should be made as a standalone class like rimeX.emulator.ImpactDataInterpolator with its own interp method. That could be called ProbabilisticImpactInterpolator. @NiklasSchwind

[perrette]

In the end for the sake of getting things done in a unified way with gridded maps, I wrote a whole new module rimeX.preproc.quantilemaps that is partly redundant with rimeX.preproc.digitize, and also contains the prediction function. Where rimeX.preproc.digitize (and associated script rime-pre-digitize), the quantilemaps module (and associated script rime-pre-quantilemap) works from netCDF files directly and handles any xarray.DataArray as input, e.g. lat, lon dimension but also with region dimension (it could also work with indicator or other dimension with minor tweaking).

Because the underlying netCDF dataset and xarray.DataArray is so structured and already presents its own methods, the need to have a class is almost gone, and a simple function (as we already have) is just fine.

However, having two different branches of code to apply the same logic is far from ideal. I would not deprecate rime-pre-ditigitize right away because the simple counting of records is a neat approach. Perhaps with a little more careful analysis the code could be written in a more abstract manner that handles both cases. And, there could be a bridge from a list of CSV records of binned (per GWL) data to the "quantile map" netCDF, in addition to the direct netCDF files -> quantile map pathway. I'll rename the issue accordingly.