message: Add note about publishing RCs to crates.io
  We've been testing out the pre-release feature of crates.io and there
  haven't been any major issues. So this updates the documentation to
  recommend publishing to crates.io even before the official release.
diff: @@ -124,17 +124,18 @@ The exact steps for an exemplary `0.2.0` release might look like this:
  2. A new `v0.2.0` branch is created for the release
  3. In the branch, the version is bumped to `0.2.0-rc1`
  4. The new commit in the branch is tagged as `v0.2.0-rc1`
  - 5. A GitHub release is created for the `v0.2.0-rc1` tag
  - 6. The changelog since the last release (stable or RC) is added to the GitHub release description
  - 7. On master, the version is bumped to `0.3.0-dev`
  + 5. The pre-release versions are published to crates.io
  + 6. A GitHub release is created for the `v0.2.0-rc1` tag
  + 7. The changelog since the last release (stable or RC) is added to the GitHub release description
  + 8. On master, the version is bumped to `0.3.0-dev`
  and the `-dev` suffix is removed from the `0.2.0-dev` changelog
  - 8. Bug fixes are cherry-picked from master into the branch and steps 4-7 are repeated until no
  + 9. Bug fixes are cherry-picked from master into the branch and steps 3-7 are repeated until no
  major issues are found in the release candidates
  - 9. In the branch, the version is bumped to `0.2.0`
  - 10. The new commit in the branch is tagged as `v0.2.0`
  - 11. The new version is published to crates.io
  - 12. A GitHub release is created for the `v0.2.0` tag
  - 13. The changelog since the last stable release (**not** RC) is added to the GitHub release
  + 10. In the branch, the version is bumped to `0.2.0`
  + 11. The new commit in the branch is tagged as `v0.2.0`
  + 12. The new version is published to crates.io
  + 13. A GitHub release is created for the `v0.2.0` tag
  + 14. The changelog since the last stable release (**not** RC) is added to the GitHub release
  description
  On master and with new planned releases, only the minor version is bumped. This makes it possible to
  @@ -146,7 +147,7 @@ The exact steps for an exemplary `0.2.3` release might look like this:
  2. A new `v0.2.3` branch is forked from the `v0.2.2` branch
  4. All bug fixes are cherry-picked from master into the `v0.2.3` branch
  5. The version is bumped to `v0.2.3-rc1` and the changelog is updated to include all fixes
  - 6. Follow Steps 5-12 of the regular release's example
  + 6. Follow Steps 4-13 of the regular release's example
  7. The release's changelog is ported back to master, removing fixes from the `0.2.3` release
  The `alacritty_terminal` crate is released in synchronization with `alacritty`, keeping the `-dev`
  