Revise Alpha/Beta guidelines iteration office hrs

Why is this change being made?

In the iteration office hours yesterday Sid mentioned that alpha, beta, incomplete features could be part of the release post (and then you can add them again in a future release post once they are more usable). At the same time, in the past we had a convention that only finished iterations, not behind feature flags, and so on should be included. I.e., they could be small iterations but should be ready for production use, and our definitions of alpha, beta etc. explicitly list them as not ready for production use: https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha-beta-ga)

This MR is to clarify when and how to notify users of an Alpha and Beta offering

Author Checklist

• Correct MR template applied (e.g blog post)
• Provided a concise title for the MR
• Added a description to this MR explaining the reasons for the proposed change, per say-why-not-just-what
• Assign this change to the correct DRI
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to your manager.
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies.
  • If the changes relate to any part of the project other than updates to content and/or data files please make sure to ping @gl-static-site-editor in a comment for a review and merge. For example changes to .gitlab-ci.yml, JavaScript/CSS/Ruby code or the layout files.

For help with failing pipelines reach out in #mr-buddies in Slack