Special relevance.
    
    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.