This has been clearly lacking while making the previous commit
but the implementation isn't that clear so let it be a separate
step.

The problem requiring the change in subsequent processors
is that these relied upon "@arch" as a flag to be inspected,
and "pkg@!arch1,arch2" on arch2 needs to take out *all* of that
fragment *including* arch1 mention as well.

Part of the cause is difference in handling: "positive" multi-match
would explode its "client" line into multiple lines to filter down
the pipeline, while "negative" multi-match *has* to keep that line
on a similarly single line (otherwise we'd end up with N-1 of those
slipping past the filter for particular architecture thus defeating
the whole purpose of "negative" matching semantics):

$ echo 'pkg@!E2K,mipsel,riscv64' |
  sed -r  ':loop; s/^((([^@]+@!)[^,]+)+),([a-zA-Z0-9_]+)/\1@!\4/; t loop'
pkg@!E2K@!mipsel@!riscv64

I've tried my best to test this specific change but it still might
introduce a regression in some corner case; feel free to report;
looks like there's a space for improvement in m-p's automated
tests department as well.

So now we can do:

  pkg@!ARCHES1,ARCHES2,arch3,arch4

and have pkg excluded on arches mentioned; the previous approach
could only offer explicit whitelists (not that it was entirely
wrong but then again, we have both ExclusiveArch and ExcludeArch
rpmtags in our spec files).