Compute upward derivative of a grid in the frequency domain

[santisoler]

Define a new derivative_upward function for computing the spatial upward
derivative of a 2D grid in the frequency domain. The function makes use of
xrft for handling Fourier transformations of xarray objects. Add a new
filters subpackage that includes FFT filters: functions that take grids in
frequency domain and return the desired filter also in frequency domain. Add
fft and ifft wrapper functions of the xrft.fft and xrft.ifft ones. Add
a new apply_filter function that takes a grid in the spatial domain, applies
fft, the filter and ifft and returns the filtered grid also in spatial domain.
Add tests for the new features and a gallery example for the upward derivative.
Add netcdf4 as requirement for testing.

Reminders:

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst and the base __init__.py file for the package.
• Write detailed docstrings for all functions/classes/methods. It often helps to design better code if you write the docstrings first.
• If adding new functionality, add an example to the docstring, gallery, and/or tutorials.
• Add your full name, affiliation, and ORCID (optional) to the AUTHORS.md file (if you haven't already) in case you'd like to be listed as an author on the Zenodo archive of the next release.

[RichardScottOZ]

Seems good - is 'vertical' terminology more used than upward?

Notes for the function could I suppose include parenthetical references to x/y after easting and northing?

[santisoler]

Thanks @RichardScottOZ for the feedback!

Seems good - is 'vertical' terminology more used than upward?

"Vertical" is more widely used, although the drawback of using it is that it doesn't explicit specify the direction of the "vertical" axe. That's why in Harmonica we decided to use "upward" for specifying the non-horizontal direction explicitly stating that it points up.

Notes for the function could I suppose include parenthetical references to x/y after easting and northing?

And a similar thing happens with x and y. We decided to use "easting" and "northing" for the horizontal axes, this way we avoid the need to constantly remember where are the "x" and "y" axes pointing (some software use "x" for northing, while some other uses for the easting).

Do you feel that using easting, northing and upward might be confusing?

[ThomasMGeo]

I would just put in the comments that upward is also called vertical, but I do like your reasoning of calling it upward.

[taschaap]

These are great! Might I suggest adding an analytic signal function to the bunch?

[santisoler]

I would just put in the comments that upward is also called vertical, but I do like your reasoning of calling it upward.

@ThomasMGeo do you mean in the comments or in the docstrings?

[ThomasMGeo]

I think either would work. Maybe just the comments to not clutter the doc strings?

[santisoler]

I think either would work. Maybe just the comments to not clutter the doc strings?

I agree. I rather avoid using vertical in the docstring in order to avoid multiple ways of referring the same thing. So no problem of adding it to the comments.

[santisoler]

I think this is ready as a first design for FFT transformations and functions. If we would like to change anything we can do it in the future, no big deal. After merging, next step would be to incorporate the FFT filters that @LL-Geo defined on #299 into this framework of filters + transformation functions.

I'm ignoring a minor CI error due to a small difference in tesseroids doctest. That issue is completely unrelated to this PR.