scheduler: split ADVISORY_NVRS into multiple ADVISORY_NVRS_N
    
    Updates with a lot of packages result in jobs with very long
    values for the ADVISORY_NVRS settings key. The longest we've had
    so far came from a KDE update with 287 packages in it:
    https://bodhi.fedoraproject.org/updates/FEDORA-2022-23a0a34ea5
    This causes a problem in the database, because the JobSettings
    table (with keys id, key, value, foreign key job_id) has indexes
    that include the value. postgres has a hard limit on how large
    a btree index entry can be, and a very long 'value' can cause
    a failure because the index entry would be too long. In the case
    of this update, the values were *just* short enough to be OK
    with openQA's database schema up until recently, but with the
    schema change that makes id and job_id bigint instead of integer,
    the index entries become too long; the result of this is that
    the schema update fails on our openQA instances. If we get an
    update with even more packages, openQA might actually blow up
    with a database error when trying to schedule the jobs.
    
    So, let's avoid this mess getting even worse in future. Instead
    of a single ADVISORY_NVRS we'll create one ADVISORY_NVRS_N per
    20 packages in the update.
    
    This does mean updates with a lot of packages in them will
    create jobs with a lot of settings, which has its own potential
    problems. A job creates one row in JobSettings per setting, we
    run about 55 jobs per update, so with this approach, that
    KDE update would create 770 more rows in that table than
    before. With 'id' as an integer, we might conceivably overflow
    it within a timeframe we care about. But with it changed to
    bigint we shouldn't.
    
    Signed-off-by: Adam Williamson <awilliam@redhat.com>