I'm not totally happy with this approach. First, I'll describe the bug,
then the solution, then what I'm not happy with.

First, the bug is that when we changed the format of the subject to a
list, we didn't think about how policies would map to subjects of
different types in a single query. Bodhi would like to make a single
query with all the artifacts it care about, and have greenwave do the
heavy lifting. It will provide a query with a koji_build, and a
bodhi_update alias, and a new original_spec_nvr nvr from the
atomic ci pipeline. The problem is that all of our policies apply
indiscriminately to all of those subjects - which can't make sense.
There is no rpmlint run on an "update".

The approach taken here is to introduce new attributes to our policies
that let them define what subjects they are relevant to. They can
specify a relevance_key or a relevance_value which makes them only
narrowly applicable to certain subjects.

I don't like that we have to have relevance_key and relevance_value
(in order to handle the strange looking original_spec_nvr). I also
don't like that "is relevance to" and "is applicable to" mean almost
exactly the same thing in english, but here in greenwave they are
defined at different scopes of the query. "applicable" applies to the
query as a whole while "relevant" applies to each item in the query's
subject.

Perhaps this can be rethought and thrown out.. but I wanted to post
something to have something to argue about.

I'll also apply this to the greenwave "stg" instance so we can poke at
it there.

Lastly, this is on top of the disjunction, branch from #62.