CI: Add the "Doctests" workflow to run doctests weekly

[seisman]

Description of proposed changes

Add a new workflow "ci_doctests.yaml" to run all doctests. This workflow is scheduled to run weekly on Sunday.

Fixes #2286.

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.
• Use underscores (not hyphens) in names of Python files and directories.

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

[seisman]

Off-topic question: Currently, we're documenting what a workflow does in the maintainers' guide, but it's very likely that we may forget to update the guides when we make changes to a workflow.

Perhaps we should only keep a short, one-sentence description for each workflow in the maintainers' guide and put a much longer description in the workflow file.

[seisman]

Ping @GenericMappingTools/pygmt-maintainers for comments on this.

[weiji14]

Maybe have a README.md under https://github.com/GenericMappingTools/pygmt/tree/v0.9.0/.github/workflows to document, so that people looking at the folder can see what the *.yml files are for? Also fine with including it in the YAML file since that will be more visible.

[seisman]

Also fine with including it in the YAML file since that will be more visible.

I'm inclined to this option because (1) we won't forget to update the workflow descriptions; (2) the workflows are more self-explanatory.

[weiji14]

Also fine with including it in the YAML file since that will be more visible.

I'm inclined to this option because (1) we won't forget to update the workflow descriptions; (2) the workflows are more self-explanatory.

Ok, so just document things in the YAML files and remove the descriptions from the doc/maintenance.md file. Can do this in another PR once this one is merged.

[weiji14]

Maybe have a README.md under https://github.com/GenericMappingTools/pygmt/tree/v0.9.0/.github/workflows to document, so that people looking at the folder can see what the *.yml files are for? Also fine with including it in the YAML file since that will be more visible.

[weiji14]

Almost ready I think, just need to comment the pull_request: line and fix the typo.

[weiji14]

Also fine with including it in the YAML file since that will be more visible.

I'm inclined to this option because (1) we won't forget to update the workflow descriptions; (2) the workflows are more self-explanatory.

Ok, so just document things in the YAML files and remove the descriptions from the doc/maintenance.md file. Can do this in another PR once this one is merged.