Ensure inputs of cosine of solar zenith angle are chunked when needed

[aulemahal]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes Cosine of solar zenith angle takes way too much memory for long datasets #1536
• Tests for the changes have been added (for bug fixes / features)
  • (If applicable) Documentation has been added / updated (for bug fixes / features)
• CHANGES.rst has been updated (with summary of main changes)
  • Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

• New function xc.core.utils._chunk_like to chunk a list of inputs according to one chunk dictionary. It also circumvents [Bug]: cannot chunk a DataArray that originated as a coordinate pydata/xarray#6204 by recreating DataArrays that where obtained from dimension coordinates.
• Generalization of uses_dask so it can accept a list of objects.
• Usage of _chunk_like to ensure the inputs of cosine_of_solar_zenith_angle are chunked when needed, in mean_radiant_temperature and potential_evapotranspiration.

The effect of this is simply that the cosine_of_solar_zenith_angle will be performed on blocks of the same size as in the original data, even though its inputs (the dimension coordinate) did not carry that information. Before this PR, the calculation was done as a single block, of the same size as the full array.

Does this PR introduce a breaking change?

No.

Other information:

Dask might warn something like PerformanceWarning: Increasing number of chunks by factor of NN. Where NN should be the number of chunks along the lat dimension, if present. That exactly what we want, so it's ok.

[coxipi]

Very nice. I'm not sure if this would be appropriate, but I had the thought that cosine_of_solar_zenith_angle and extraterrestrial_solar_radiation could manage the chunking themselves by accepting an argument chunks. Since they only accept those coordinate arrays, seems like something that will happen all the time. But, perhaps, we don't want to do these kinds of operations at this low level. Anyways, just a thought I'm sharing since I had nothing more to say, LGTM.

[aulemahal]

@coxipi I think that idea is better indeed!

I changed to a chunks arguments in the cosine function itself. The user still needs to know to pass that argument, but it's much shorter!

[aulemahal]

@coxipi The previous CI run failed because of two bugs:

1. I was chunking all the time, even when not needed. This is now fixed.
2. SPI uses a function that was not implemented for dask arrays with xarray <= 2023.3.0 (ds.pr.groupby(...).first())
   Haha I think this was my suggestion...

And with python 3.8, xarray can't go over 2023.1.0, so SPI and SPEI will fail for dask arrays in python 3.8.

I suggest we do nothing about this as the plan is to drop 3.8 (and those older xarrays) in january.

[coveralls]

coverage: 90.433% (-0.006%) from 90.439%
when pulling ce2c565 on fix-1536
into 6efc676 on master.