Add a two-week delay to Wasmtime's release process

[alexcrichton]

This commit is a proposal to update Wasmtime's release process with a
two-week delay from branching a release until it's actually officially
released. We've had two issues lately that came up which led to this proposal:

• In fix(wasi): enable all WasiFiles to be pollable (#3913) #3915 it was realized that changes just before the 0.35.0 release
  weren't enough for an embedding use case, but the PR didn't meet the
  expectations for a full patch release.

• At Fastly we were about to start rolling out a new version of Wasmtime
  when over the weekend the fuzz bug Register allocation panic with simd comparison #3951 was found. This led to the
  desire internally to have a "must have been fuzzed for this long"
  period of time for Wasmtime changes which we felt were better
  reflected in the release process itself rather than something about
  Fastly's own integration with Wasmtime.

This commit updates the automation for releases to unconditionally
create a release-X.Y.Z branch on the 5th of every month. The actual
release from this branch is then performed on the 20th of every month,
roughly two weeks later. This should provide a period of time to ensure
that all changes in a release are fuzzed for at least two weeks and
avoid any further surprises. This should also help with any last-minute
changes made just before a release if they need tweaking since
backporting to a not-yet-released branch is much easier.

Overall there are some new properties about Wasmtime with this proposal
as well:

• The main branch will always have a section in RELEASES.md which is
  listed as "Unreleased" for us to fill out.
• The main branch will always be a version ahead of the latest
  release. For example it will be bump pre-emptively as part of the
  release process on the 5th where if release-2.0.0 was created then
  the main branch will have 3.0.0 Wasmtime.
• Dates for major versions are automatically updated in the
  RELEASES.md notes.

The associated documentation for our release process is updated and the
various scripts should all be updated now as well with this commit.

[alexcrichton]

Some examples of PRs:

• PR on the 5th of the month to update the major version number
• PR on the 20th to main to update the release date
• PR on the 20th to release-x.y.z to make the release
• PR for a patch release, made to release-x.y.z

Note that I've included a major version bump to 0.36.0 in this PR since that's the next version of Wasmtime, and that'll be necessary to bootstrap this process. That's because main will always be a version ahead of the latest release branch.

[github-actions]

Subscribe to Label Action

cc @cfallin, @fitzgen

This issue or pull request has been labeled: "cranelift", "cranelift:meta", "cranelift:module", "cranelift:wasm", "isle", "wasmtime:docs"

Thus the following users have been cc'd because of the following labels:

• cfallin: isle
• fitzgen: isle

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[alexcrichton]

I added some more notes here on performing a security release, specifically indicating that we should open a version-bump PR ahead-of-time as we announce the intent to make patch releases. This gives us some extra runway to fix any issues with CI that arise, for example the backports included in #3984.

[cfallin]

Looks good overall; the advanced sed magic feels a little brittle but given that we will review all the PRs manually before merging, let's see how it works I guess (props for automating even the little nits like editing the date on main though!).

[cfallin]

for maximum clarity it might be good to say here that the PR should not include the security patch at this point (that comes below)