frontend: generate build_chroots for resubmitted SRPM-upload builds
    
    Fix #1531
    Fix #1619
    Fix RHBZ 1906062
    Fix RHBZ 1896747
    
    The logic for resubmitting builds is more complicated and conditioned
    to differ for more scenarios than one would expect. It would be worth
    it to either unify the logic or rework it to keep the case-specific
    code together instead of having it all over the place.
    
    Let me elaborate on what I found. There are (at least) three different
    scenarios:
    
    1) If you resubmit a build from whatever source and specify some/all
    chroots, then build_chroots are generated and committed at the same
    time as the new build itself. By default only failed build_chroots are
    selected and it is up to a user to update the chroots checkboxes as
    appropriate.
    
    2) If you resubmit a build from everything else than SRPM
    upload (e.g. SCM method) and not specify any chroots, all project
    chroots are going to be used. However, they are not generated straight
    away (i.e. in the build detail, the results box doesn't show any
    table). They are generated once backend finishes the SRPM build and
    then requests to update its status in the database.
    
    3) If you resubmit a build from SRPM-upload and select any chroots
    then this is a case (1), however, if you don't specify any chroots,
    the issues linked above, happen. That's because if we resubmit
    SRPM-uploaded build, we skip the importing part altogether, so there
    is no update from the backend. I am changing the behavior of this case
    and this case only, to use all project chroots (same as (2)) but to
    generate them straight away (as it is done in the (1) case).