Ensure dtype is preserved after regridding

[stephenworsley]

Adresses #238.

[stephenworsley]

Note: this will still change the dtype if you start with integer data (by design). This does mean that the dask array also will have to be changed to better align with the underlying data in this case. This should be a seperable issue which can be addressed in its own PR.

[codecov]

Codecov Report

Attention: Patch coverage is 98.71795% with 1 line in your changes missing coverage. Please review.

Project coverage is 98.85%. Comparing base (a50b2b8) to head (b587641).
Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
esmf_regrid/schemes.py	85.71%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #239      +/-   ##
==========================================
- Coverage   98.85%   98.85%   -0.01%     
==========================================
  Files          36       37       +1     
  Lines        3855     3929      +74     
==========================================
+ Hits         3811     3884      +73     
- Misses         44       45       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pp-mo]

I'm not convinced that there aren't a few more cases to address here. I think I would create test examples where both weights + source_array can be integer / float32 / float64, and check that output dtypes are as expected in all those cases.
But I may have missed that dtypes for the weights array are always known, or more limited ?

[github-actions]

@SciTools-incubator/esmf-regrid-devs This pull-request is stale due to a lack of activity in the last 90 days. Remove stale label or comment, otherwise this pull-request will close automatically in 7 days time.

[CLAassistant]

All committers have signed the CLA.

[pp-mo]

Basically OK except for a possible tidy in the tests.