Update the GitLab Release job

What does this MR do?

1. Makes the stable gitlab release job dependent on all artifacts release jobs.
2. Adds the filepath.
3. Updates the assets naming a little.
4. Disables downloading artifacts from dependent jobs (as these are not needed).

Additionally it fixes one thing found during recent security release and one introduced by mistake during that release:

1. By setting CI_PROJECT_ID explicitly we will restore the desired execution when the manual job executed on the security fork creates the release entry in the canonical fork (this was broken when we've switched from the manual script to using release: keyword).

2. By setting before_script: [] it will fix a bug in this job introduced with 14.5.2, 14.4.2 and 14.3.4 security release.

Why was this MR needed?

1. Currently the job is one of the jobs in the release stage, executed concurrently with the others. Therefore it is possible that, for example, the job that releases Docker images, uploads the packages to packages.gitlab.com or uploads all release artifacts to S3 will fail while the stable gitlab release will succeed.

   As some users are using the https://gitlab.com/gitlab-org/gitlab-runner/-/releases page as the source of what was really released, we should make sure that in case of release failures, this one will be not executed - until we will fix the release pipeline.

   By adding the needs definition (which since GitLab 14.2 can refer to jobs defined in the same stage!) we can define such relation and requirement.

2. The filepath option allows to maintain an URL within the project path that will redirect to the external object storage or wherever the release asset is available (and pointed by the existing url option).

   With that we will be able to point our installation docs to links like https://gitlab.com/gitlab-org/gitlab-runner/-/releases/v14.6.0/downloads/binaries/gitlab-runner-darwin-amd64 instead of revealing the object storage details with path like https://gitlab-runner-downloads.s3.amazonaws.com/v14.6.0/binaries/gitlab-runner-darwin-amd64. While the final URL will still be public (as GitLab will redirect the caller to that URL), it have two advantages:

   1. We link to the project itself which is way easier to remember than needing to known a totally external service URL (like gitlab-runner-downloads.s3.amazonaws.com domain in our example and the pattern of how we put different releases in our bucket).

   2. In case if we will decide that we want to switch from S3 to GCS or, for example, GitLab's generic packages registry, we can do that in a way totally transparent for the users. There is still a work that needs to be done by maintainers: copy files to the new location and update all release entries to point to the new URLs, but from user perspective a file available at project/-/releases/v14.6.0/downloads/assert.file is still available at that URL, no matter what Object Storage service at what URL is in fact hosting the asset.

3. Currently the names are not fully representing what assets they are linking to. The different asset types are also mixed, as the list is sorted alphabetically. By adding the type: prefix, we will group the different asset types together and make it more obvious which files are the binaries and which are the packages.

   Currently we also mix the link to the documentation page among other asset links. This should be part of the description, which this MR introduces.

   Finally, the assets list got two more important files: checksums file and checksums GPG signature. Both useful for users who like to verify if the downloaded assets are what they should be. Currently to get these files one would need to search for them in our S3 bucket having the others link as the only connection from the release page.

What's the best way to test this MR?

What are the relevant issue numbers?