Improvements around current errata workflow

We should provide some mechanism to ensure that, when releasing an errata record, in addition to not referencing packages from the wrong modules (we already figured this out as part of another issue), we avoid situations like the one we actually have with perl-IO-Socket-SSL module, which the same name:stream:version is built in/for different contexts and might lead to problems when releasing the errata into updateinfos of different repos (or archs).

In addition to some improvements that need to be done around modules, we maybe need to add some more fine-grain control of the package mappings that we do for erratas.

These mappings can occur:
- When the errata record is added into the BS
- First check for matching pkgs production repos. If found, they’re added as “released”
- If there’s no match, try find one in built rpms inside the BS. If there’s a match, it’s added as “proposal”
- When a package that corresponds to an errata package is built on the BS, we add the mapping as “proposal”

Then, when manually adding the packages that we want to reference to in the errata, we might want to have more control over what is going to be added to the errata. For instance, there’s a build that has all packages for all arches except s390x (that we built after), how can we ensure that our errata information is consistent among repos/arches?

Also, regarding perl-IO-Socket-SSL module. Shall we revisit how we build modules/release erratas related to this module?