Update the release drafter workflow and configurations

This project uses the Release Drafter workflow to draft the next release notes (only visible to maintainers) from PRs.

• We’re using the release-drafter/release-drafter@v5.8.0, but the latest version is v5.13.0. We should bump it to the latest version (we have set up the dependbot to bump the actions automatically, but the bot runs on every Tuesday, so we won’t see it happen before v0.3.0 release). [Done in #889]

• Some new features were added since v5.8.0. One feature that may be useful to us is https://github.com/release-drafter/release-drafter/pull/582, which means we can write the full URL of PRs in the release notes, instead of running the sed command to replace #NUMBER to #NUMBER + URL.

• The release notes on GitHub are written in markdown, but the changelog are written in ReST. When we’re going to make a release, we need to copy the draft release notes to changes.rst, convert it to ReST, create a PR and remove some items with low importance, merge the PR and then update the github release notes again. I found it very inconvenient because the two different markdown languages. I feel it would be much easier if we also use markdown for changelogs, i.e., changes.md instead of changes.rst.

• Changes are grouped into several categories: “Highlights”, “New Features”, “Enhancements”, “Documentation”, “Bug Fixes”, “Maintenance”, and “Deprecations”. I don’t like the current order of these categories. IMHO, these categories should be sorted by importance from the readers’ point of view. Thus, the order should be

  1. “Highlights”
  2. “New Features”
  3. “Enhancements”
  4. “Deprecations”
  5. “Bug Fixes”
  6. “Documentation”
  7. “Maintenance”

[seisman]

As we are very close to making the v0.3.0 release, I think it may be better to work on this issue AFTER v0.3.0 release.

@willschlitzer will work on the final changelog/release notes of v0.3.0. After he finishes it and releases v0.3.0, we will have 4 contributors (@leouieda, @weiji14, @willschlitzer and @seisman) who have some experience with making PyGMT releases. Then we can better discuss if we want to make some changes to the release process.

[weiji14]

Just discovered MyST today and I believe it should address most of the ReST changelog pain points by switching things to markdown! It also opens up the possibility of converting some of *.rst files in doc from restructured text to markdown (much more new-contributor friendly) but that’s for another discussion 😄

* [ ]  Some new features were added since v5.8.0. One feature that may be useful to us is [release-drafter/release-drafter#582](https://github.com/release-drafter/release-drafter/pull/582), which means we can write the full URL of PRs in the release notes, instead of running the `sed` command to replace `#NUMBER` to `#NUMBER + URL`.

See https://github.com/GenericMappingTools/pygmt/pull/941/files#r579724762. Need to set change-template: '* $TITLE [#$NUMBER]($URL)' in .github/release-drafter.yml file.

* [ ]  The release notes on GitHub are written in markdown, but the [changelog](https://github.com/GenericMappingTools/pygmt/blob/master/doc/changes.rst) are written in ReST. When we're going to make a release, we need to copy the draft release notes to `changes.rst`, convert it to ReST, create a PR and remove some items with low importance, merge the PR and then update the github release notes again. I found it very inconvenient because the two different markdown languages. I feel it would be much easier if we also use markdown for changelogs, i.e., `changes.md` instead of `changes.rst`.

Review the PR at #941, where changes.md is now used instead of changes.rst!

* [ ]  Changes are grouped into several categories: "Highlights", "New Features", "Enhancements", "Documentation", "Bug Fixes", "Maintenance",  and "Deprecations". I don't like the current order of these categories. IMHO, these categories should be sorted by importance from the readers' point of view. Thus, the order should be
  
  1. "Highlights"
  2. "New Features"
  3. "Enhancements"
  4. "Deprecations"
  5. "Bug Fixes"
  6. "Documentation"
  7. "Maintenance"

This order looks ok to me. Points 4, 5, 6 could be reordered differently perhaps but no strong opinions on this.