Changed behaviour of "buffer" argument in get_rasterdataset

[roeldegoede]

After migrating to v1, the buffer argument in the get_rasterdataset argument works differently, which has very big consequences for the clipping/sliicing of the data. It seems that the buffer argument should be provided in meters, which in essence is more aligned with for exampe get_geodataframe, and not any longer in pixels. Nonetheless, providing "pixels" seems to be more user friendly.

For example, when you are using ERA5 data with 0.25 degrees resolution for a small SFINCS domain, the get_rasterdataset now only returns a dataset with length x=1, y=1, which is therefore no 2D raster anymore. Solution for this is to provide a buffer of 25km or so, to still get some surrounding points as well. In the old HydroMT, where we were using the "pixels" instead of "meters", a buffer of 2 pixels was always sufficient, independent on the data resolution.

I don't think there is a right or wrong here, but I was wondering whether this was designed as such on purpose or by accident.

[hboisgon]

I also discovered this new behavior and I'm not too fond of it as this is is too much dependent on the raster resolution and users would need to change this parameter way too much (eg extreme case of 25km raster versus 10m where you would blow up the memory for no reason).

I was not very involved there so I'm not sure if this is on purpose or by accident so will put it back on the table.

[LuukBlom]

Once this PR gets merged we can unskip the remaining tests in the v1 branch for hydromt_wflow