sync_updates: allow Bugs for same bug ID but different milestone
    
    The `sync_updates` code was written to only allow an update to
    be associated with a single Bug for any given bug ID. But that's
    not actually valid, because if a bug is for e.g. AcceptedFE for
    Beta and AcceptedBlocker for Final, we encode this in the DB as
    *two* Bugs with the same bug ID but different milestones. So we
    need to allow the sync code to associate multiple Bugs for the
    same bug ID with an update, *if they have different milestones*.
    
    There was a loophole in the old code that meant it happened to
    do the right thing if both the Bugs (representing both accepted
    states) were picked up in the same sync - i.e. if the bug was
    accepted as *both* Beta FE and Final blocker *between two syncs*.
    But if the bug was accepted as one of the two, then a sync ran,
    then it was accepted as the other and then another sync ran, the
    second Bug (representing the second accepted state) was not
    added. I think the loophole was an oversight and not intentional,
    so I fixed it in this change, just in case we do somehow hit a
    case where the query returns multiple Bugs with the same ID and
    milestone (though there's no reason it ever should). The change
    does make the code slightly less efficient because it now always
    has to run the db query, but I don't think that's avoidable.
    
    The symptom of this is, when you have an affected case, the bug
    will appear on both the Beta and Final lists, but on one of the
    two, the 'updatelabel' (the yellow 'testing' or green 'stable'
    blob in the Updates column) will be missing, and in the Requests
    tab, you will only get request text for one of the milestones
    even though you should get it for both. For e.g. till today we
    had bug #1872922 affected by this - it was both F33 Beta
    AcceptedFE and F33 Final AcceptedBlocker, and the bug showed in
    both bug lists, but though the update was in testing and queued
    for stable, the updatelabel only appeared on the Final bug list
    (not the Beta one) and the requests text for Beta didn't include
    the update in the "stable push" list even though it should have
    done, while the requests text for Final was correct.
    
    It happened that the tooltip for the Updates column always
    worked, though, which was the cause of the weird 'ghost update'
    effect where there was no updatelabel but if you hovered over
    the empty space, the update appeared in a tooltip.
    
    Signed-off-by: Adam Williamson <awilliam@redhat.com>
    
    Merges: https://pagure.io/fedora-qa/blockerbugs/pull-request/137