[sdba] Refactor interp_on_quantiles

[aulemahal]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes #xyz
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)
• HISTORY.rst has been updated (with summary of main changes)
  • Link to issue (:issue:number) and pull request (:pull:number) has been added.
• bumpversion patch has been called on this branch
• The relevant author information has been added to .zenodo.json

What kind of change does this PR introduce?

I though the changes in #914 would address a bug I saw while computing ESPO-R. However, I had forgotten about the splitting pathways for group='time' vs group='time.prop'. That also meant testing was not sufficient. This PR changes xclim.sdba.utils.interp_on_quantiles so that:

• All NaNs in the coordinates are dropped. Minor modification from the Extremes' PR, but dropping everything explicitly, instead of relying on interp1d, has the advantage that NaNs in the new coord are not considered "out of bounds", but NaNs. They return NaN in the output, not an extrapolated value.
• All NaNs in the new coordinates are dropped. In the 2D case, with 'nearest', NaNs would cause QHull errors.

Does this PR introduce a breaking change?

• Not really.

Other information:

The docstring was improved.

I realized that method='cubic' does not respect the constant extrapolation as set by extrapolate_qm... I added a note to the doc, but I'm not sure what to do here. @huard ? The logic we used works well with 'nearest' and 'linear', but as 'cubic' fetches a third point it estimates something else.

EDIT:
I compared the performance before and after the change and it is insignificant. griddata and interp1d are much slower than any numpy overhead I added, so I did not see any timing difference.

[coveralls]

Coverage decreased (-0.08%) to 90.654% when pulling 68dd5c2 on sdba-fullskipna into 4267286 on master.

[aulemahal]

Last commits went deeper and refactored interp_on_quantiles.

• Extrapolation is now handled by that function, without need to use extrapolate_qm. Changes to the adjustment methods are internal and nothing has changed in the API for the normal user.
• However, extrapolation is now better handled. With interp='cubic', the constant extrapolation is fixed.
• On a side note, I removed the interp argument of Grouper's init. It served almost no purpose, introducing more noise than doing good. It stays on Grouper.get_index as boolean only. It only matters with monthly grouping, so... almost never.
• A bit of code refactor.

Should we remove extrapolate_qm? It is not used in the adjustment methods anymore.

[huard]

Does it make sense to repurpose test_extrapolate_qm to test the new extrapolation code ? I know its implicitly tested elsewhere, but still.

[aulemahal]

The new extrapolation code is explicitly tested in test_interp_on_quantiles! (see expe).

I would rather suggest to remove extrapolate_qm? I liked the way it dealt with the situation, but sadly griddata demands more complexity...

[huard]

All good then.
Ok for removal, I would be surprised anyone used that function directly. If we want to do it by the book, we could deprecate it for the next release before removal.