Automate and stabilize the DAST release process

What does this MR do?

This MR replaces the previous deploy step with an automated one-click release process. The DAST.gitlab-ci.yml Rails template will pin the version to the major DAST version created by this release.

Details, details

• DAST is a one click release. It automatically creates a Git tag, tags DAST Docker images, and creates the GitLab release.
• The version and release notes are determined from the CHANGELOG.md. For this reason, future additions should be made in the same format.
• The Docker image that was built on the master gets promoted into production using Docker tags. What we built and tested is what gets released.
• The release tags all of the things. For example, a 1.5.4 release tags dast:1, dast:1.5, dast:1.5.4, dast:latest and dast:12-6-stable.
• Releases can only be made on the master branch. This ensures only approved changes are released.
• Releasing creates a release for the virtual "production" environment. I suggest we restrict releasing to maintainers of DAST (ie. members of Secure).
• A private token is used to authenticate to the GitLab API. The API is used to create releases.
• If a release for 1.5.4 already exists, then running the job again will fail. If release is broken, delete the old one before releasing again.
• Once a DAST release is created, it will never change. This differs from the current process, and is very much intentional.
• Previous releases of DAST (e.g. dast:11-10-stable) will not change from as soon as this MR is merged.
• Releasing is a manual process. We can decide as a team what the process is for who/when can run it.
• There is now only one Docker file. I don't believe we need both (please correct me otherwise).
• If we decide to release a new major version of DAST, then we will also need to update the DAST.gitlab-ci.yml to depend on the new major version.
• When we start a new iteration, we should update the supported-gitlab-runner.txt file to contain the new iteration tag e.g. 12-6-stable.

Known regressions

• Assets aren't included on the release page (.zip file etc of DAST codebase). We can add this back if required.

What happens next

• Solicit feedback from peers
• Write documentation on how to release, describe the process for what happens during a major release.
• Uncomment unsafe fields from ci config
• Review/Approval/Merge
• Release to verify that it works as intended
• Update the Rails DAST.gitlab-ci.yml to depend on dast:1, not dast:12-6-stable.
• We will review whether or not to keep dast:12-6-stable style tags at the next major GitLab release.

Future improvements

• We can remove images from registry.gitlab.com/gitlab-org/security-products/dast/[branch name] once the branch is merged
• We can add a validator to make sure that any additions to the CHANGELOG.md adhere to the specification
• If we're on version 2.0.0 and need to fix a P1 bug on 1.9.8, we may have to release 2.0.1 and 1.9.9. There is a way to do this, I can document it if required.
• If DAST produces a report format that is "old", the job log could output that the version of DAST should be upgraded. Probably best to do this after the Common Report Format changes (i.e. do it for all Secure jobs).

This MR is in part a solution to gitlab-org/gitlab#33364 (closed).