Add contributing guides for wrapping a GMT module

[maxrjones]

Description of proposed changes

This PR adds the guidance from #1599 to the contributing guide and shortens the pull request reminders based on the conversation at #1629 (comment).

Fixes #1599

Preview: https://pygmt-dev--1687.org.readthedocs.build/en/1687/contributing.html#wrapping-a-gmt-module

[willschlitzer]

I think we should either track the module updates in a project board (my preference) or an issue, but not both.

[maxrjones]

Do you think we should abandon the 'Wrapper for <module-name>' issues entirely or keep the issues/issue-template and just move the checklist to the project board? I think the main benefit of the issues is that from my understanding any GitHub user can open/comment on an issue whereas writing on the project board requires special permissions.

[willschlitzer]

I think the project board works better for tracking the progress of wrapping a module, and that having a separate issue for wrapping the function is a bit redundant. I see what you mean about the benefits of issues being open to everyone, but my thought is that wrapping modules is a pretty routine process and doesn't need to first be raised as an issue (unlike a bug or a feature request). We can add some/all of the GMT modules to the project board to track their process. Users who don't have write permission are still free to open up an issue requesting a module/feature (or a pull request! 🤞) as a way to let us know that a certain feature would be useful to them.

[seisman]

the benefits of issues being open to everyone

IMHO, issues are also more visible than project boards, so that we may have more potential contributors helping wrap new modules and add more aliases.