Packaging: remove redundancies in package build pipelines

What

This MR builds on the work done in !13669 (merged) and !13593 (merged) and refactor the current packages pipelines, moving them from the toplevel pipelines to the child pipeline for debian packages.

in partucular: the job job_build_dpkg was duplicated in the child pipeline by the job job_build_debian_package_current. it's the same job, but re-use the dependencies images instead of building everything from scratch every time. The job job_build_dpkgwas left as it is because it is also used in the release pipelines. This MR removes the duplicated job from the before_merging pipelines and replace the job job_build_dpkg with job_build_debian_package_current in the release pipelines.

Why

After !13669 (merged) and !13593 (merged) current packages pipelines are duplicated. This MR removes the duplication and refactor the code to add the child pipeline to the release pipeline.

How

To remove the current packages pipeline from toplevel, I had to move some type definitions in the Common module. This is necessary because the debian_repository child pipeline is now called both from the code_verification module and the release_tag module and creates different pipeline w.r.t the pipeline type that created it.

Manually testing the MR

Make sure that both the test pipeline the release pipeline are correct.

Since I've touched the release pipelines is important to check that all jobs are going to be executed. Also, because the code for the child pipeline is now different w.r.t. the type of pipeline, I've added multiple yaml file containing different pipelines, even though many of the look very similar.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR