load_earth_age: Add inline examples

[willschlitzer]

Add an inline example for load_earth_age.

Addresses #2225

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.
• Write detailed docstrings for all functions/methods.
• If wrapping a new module, open a 'Wrap new GMT module' issue and submit reasonably-sized PRs.
• If adding new functionality, add an example to docstrings or tutorials.

Slash Commands

You can write slash commands (/command) in the first line of a comment to perform
specific operations. Supported slash commands are:

• /format: automatically format and lint the code
• /test-gmt-dev: run full tests on the latest GMT development version

[yvonnefroehlich]

The following goes beyond this PR. At the moment I am wondering if the two messages blow are contradicting:

When running

from pygmt.datasets import load_earth_age
grid = load_earth_age(resolution="30m")

It says:

pygmt-session [WARNING]: Remote dataset given to a data processing module but no registration was specified - 
default to gridline registration (if available)

In the documentation users find:

registration (str) – Grid registration type. Either "pixel" for pixel registration or "gridline" for gridline registration. Default is None, where a pixel-registered grid is returned unless only the gridline-registered grid is available.

[willschlitzer]

The following goes beyond this PR. At the moment I am wondering if the two messages blow are contradicting:

When running

from pygmt.datasets import load_earth_age
grid = load_earth_age(resolution="30m")

It says:

pygmt-session [WARNING]: Remote dataset given to a data processing module but no registration was specified - 
default to gridline registration (if available)

In the documentation users find:

registration (str) – Grid registration type. Either "pixel" for pixel registration or "gridline" for gridline registration. Default is None, where a pixel-registered grid is returned unless only the gridline-registered grid is available.

As I understand it, this is coming from the default registration in GMT. Since an argument isn't passed to registration in this example, the API returns this warning.

[seisman]

The following goes beyond this PR. At the moment I am wondering if the two messages blow are contradicting:
When running

from pygmt.datasets import load_earth_age
grid = load_earth_age(resolution="30m")

It says:

pygmt-session [WARNING]: Remote dataset given to a data processing module but no registration was specified - 
default to gridline registration (if available)

In the documentation users find:

registration (str) – Grid registration type. Either "pixel" for pixel registration or "gridline" for gridline registration. Default is None, where a pixel-registered grid is returned unless only the gridline-registered grid is available.

As I understand it, this is coming from the default registration in GMT. Since an argument isn't passed to registration in this example, the API returns this warning.

See #1929 for the related issue report. We need to handle this in a separate PR.

[yvonnefroehlich]

The following goes beyond this PR. At the moment I am wondering if the two messages blow are contradicting:
When running

from pygmt.datasets import load_earth_age
grid = load_earth_age(resolution="30m")

It says:

pygmt-session [WARNING]: Remote dataset given to a data processing module but no registration was specified - 
default to gridline registration (if available)

In the documentation users find:

registration (str) – Grid registration type. Either "pixel" for pixel registration or "gridline" for gridline registration. Default is None, where a pixel-registered grid is returned unless only the gridline-registered grid is available.

As I understand it, this is coming from the default registration in GMT. Since an argument isn't passed to registration in this example, the API returns this warning.

See #1929 for the related issue report. We need to handle this in a separate PR.

Thanks @seisman for pointing out the related issue!