703 warn user when pearsonr returns nan + a flag enable or disable the warning message (default is disable)

[JinghanFu]

Please work through the following checklists. Delete anything that isn't relevant.

Development for new xarray-based metrics

• Works with n-dimensional data and includes reduce_dims, preserve_dims, and weights args.
• Typehints added
• Add error handling
• Imported into the API
• Works with both xr.DataArrays and xr.Datasets if possible

Docstrings

• Docstrings complete and follow Napoleon (google) style
• Maths equation added
• Reference to paper/webpage is in docstring. The preferred referencing style for journal articles is APA (7th edition)
• Code example added

Testing of new xarray-based metrics

• 100% unit test coverage
• Test that metric is compatible with dask.
• Test that metrics work with inputs that contain NaNs
• Test that broadcasting with xarray works
• Test both reduce and preserve dims arguments work
• Test that errors are raised as expected
• Test that it works with both xr.DataArrays and xr.Datasets

Tutorial notebook

• Short introduction to why you would use that metric and what it tells you
• A link to a reference
• A "things to try next" section at the end
• Add notebook to Tutorial_Gallery.ipynb
• Optional - a detailed discussion of how the metric works at the end of the notebook

Documentation

• Add the score to the API documentation
• Add the score to the included list of metrics and tools

[tennlee]

@nicholasloveday I think this PR is interesting from the perspective of what kinds of conditions should raise a user warning. Perhaps for all our methods, anything which is all NaN should raise a user warning? Correct setting of NaNs is intended behaviour, so doesn't indicate a program failure. On the other hand, something being entirely NaN could be an indication of a data issue or user error, and a warning could be useful. We should probably consider adopting something consistent across the codebase. Take a look at what @JinghanFu has done in this example and have a think. This work was done because @durgals mentioned it following his KGE work as being useful. @durgals you might also like to make a comment about what kinds of user warning should perhaps be raised across all our methods. Thanks @JinghanFu for putting together a concrete example for us to discuss.

[JinghanFu]

@tennlee Thank you very much for your guidance throughout the day!! Looking forward to joining the whole PyCon next year and contributing more!