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.

CONTRIBUTING.md

@@ -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`