Build and publish the next version of DAST in the CI pipeline

What does this MR do?

This MR creates the concept of the next/future/next major version of DAST so that we can decouple the time a breaking change is built by a DAST engineer from the time that the breaking change is released to DAST customers.

The CI pipeline will create two DAST images for a build on the master branch, the current image as it does now, and the "next" version. For example, if the changelog is up to 1.5.1, then the pipeline will create dast:1.5.1 and dast:2.0.0-alpha.

Using a file created by the Docker build, DAST Python is able to determine the now/next DAST with the configuration value Configuration.next_major_release. This allows the engineering team to build breaking features in DAST prior to the release date of the major release. This is an important strategy to mitigate the risk of the team not delivering on time.

For example, the next major release is DAST. We know that site/spider/@version/@generated fields will be removed. This MR means the engineering team can write something like the following code:

    if c.config.next_major_release:
        c.dast_report_formatter = c.security_report_formatter

This causes the "current" DAST to output the ZAP fields as normal, while the "next" DAST excludes them. At the time of releasing "next" (e.g. dast:2.0.0), it is simply a case of removing all of the feature toggles and updating the changelog to the new major version.

While the above example is trivial, it becomes less trivial in combination with other breaking changes: updating Browserker, the operating system, browser, etc. We don't want to have to do all of that in the same month that we release.