Document and codify the release process

The `wasmtime` release procees seems like it's been a bit ad-hoc up to
this point, so I figured it'd be good to try to document what we do
today and codify what should be done as well as a form of release
checklist.

I've noticed that we have a number of releases (like v0.11.0) but the
`Cargo.toml` files in the repository don't reflect the current version
of `wasmtime`. Additionally I've noticed that the [most recent release]
ended up having failed tests because `Cargo.toml` was modified but
`Cargo.lock` wasn't updated. I'm hoping that by having a checklist we
can avoid these sorts of accidental issues in the future!

[release]: https://github.com/bytecodealliance/wasmtime/runs/434690272

docs/contributing-release-process.md

@@ -0,0 +1,25 @@
+# Release Process
+
+This is intended to serve as documentation for wasmtime's release process. It's
+largely an internal checklist for those of us performing a wasmtime release, but
+others might be curious in this as well!
+
+To kick off the release process someone decides to do a release. Currently
+there's not a schedule for releases or something similar. Once the decision is
+made (there's also not really a body governing these decisions, it's more
+whimsical currently, or on request from others) then the following steps need to
+be executed to make the release:
+
+1. `git pull` - make sure you've got the latest changes
+2. Update the version numbers in `Cargo.toml` for all crates
+  * Edit `scripts/bump-wasmtime-version.sh`, notable the `version` variable
+  * Run the script
+  * Commit the changes
+3. Send this version update as a PR to the wasmtime repository, wait for a merge
+4. After merging, tag the merge as `vA.B.C`
+5. Push the tag to the repository
+  * This will trigger the release CI which will create all release artifacts and
+    publish them to GitHub releases.
+6. Run `scripts/publish-all.sh` to publish all crates to crates.io
+
+And that's it, then you've done a wasmtime release.