Add instructions for wrapping new 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

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

[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.

[weiji14]

Might need to get a newer example once we go with the long option standard in #1932.