Forgot to remove this from the python version when I did the maven version

Once the image is shown to be working, we can release a new fossa-with-cache container and update these files again

This version of GitLab renamed the job template to 'cyclonedx-reports' (instead of 'cyclone-dx-reports').

We need to have this here because we are trying to add a new "base class" for the gemnasium job, and GitLab CI doesn't let you add
one, only replace the list.

As of GitLab 15.0, the 3.9 python image is the default and no longer needs to be overridden. This special image name, which was
created as a stop-gap during GitLab 14.x, will eventually be deleted. Better to upgrade it now.

Specify the PIP_REQUIREMENTS_FILE to use the fully frozen version, generated by the compile-and-unit-test stage

Revert "Specify the PIP_REQUIREMENTS_FILE to use the fully frozen version, generated by the compile-and-unit-test stage"

This reverts commit 029f0697.

Conflicts:
	scanners/gitlab-ultimate.yml

The default version uses python 3.6, and that doesn't work with Wellbore Domain Services. So, we upgrade to this temporarily
provided image until GitLab produces a new default, which is slated for version 15.0

This allows the maven based jobs (gemnasium-maven-dependency_scanning / spotbugs-sast) to continue managing the .m2 cache, but
doesn't impose this complexity on parts of the pipeline that don't work with maven logic.

These jobs all depend on the compile-and-unit-test operation, and for maven jobs, the target directories with built executables and
the .m2 cache will both be present. By supppressing the compilation, this not only speeds up execution, but also removes the need to
"teach" the SAST jobs about the proper way to build the projects.

Upgrade to fossa-with-cache 0.4, which sets the specific python version to match the build/python.yml image

GitLab now supports dependent jobs within the same stage; so we can utilize this layout

This is a tradeoff decision. This direction forces hard and fast failure when the scanners do not run, pre-empting the attention of
the developer to solve scanner issues rather than the issue of their MR. This helps prevent scanner failures from being neglected
for so lang as to be useless.

Specify the PIP_REQUIREMENTS_FILE to use the fully frozen version, generated by the compile-and-unit-test stage