Dissociate git2pack & pack2bin into 2 jobs

For now, the gmkpack version of build step of a Davai experiment is made of one job containing:

the initialization of small files for the "wait4build" task to know which tasks it is waiting for ("wait4build_init")
a loop on compilation flavours for the creation of the pack(s) and population with modified files (gitref2pack)
a loop on compilation flavours for the compilation and links editions of binary executables (pack2bin)

        Wait4BuildInit(tag='wait4build_init', ticket=t, **kw),  # (re-)initialize list of tasks to be waited for
            Family(tag='gmkpack', ticket=t, nodes=[
                # Two loops rather than one with both tasks in, so that packs are created anyway if compilation fails
                LoopFamily(tag='loop_g2p', ticket=t,
                    loopconf='compilation_flavours',
                    loopsuffix='.{}',
                    nodes=[
                        GitRef2Pack(tag='gitref2pack', ticket=t, **kw),
                    ], **kw),
                LoopFamily(tag='loop_p2b', ticket=t,
                    loopconf='compilation_flavours',
                    loopsuffix='.{}',
                    nodes=[
                        Pack2Bin(tag=gmkpack_executables_block_tag, ticket=t, **kw)
                    ], **kw),

This causes a few issues:

both steps run on the same node reservation/QOS (login vs. compute nodes on belenos, nf/np QOS on ECMWF's Atos) - however, these 2 steps don't have the same specifications:
- the gitref2pack step requires little resources (1 thread) and may require internet connexion for bundle download (main pack or davai from a bundle) - this connexion is not available on compute nodes for instance
- the pack2bin step may require a larger number of threads/CPUs to speed-up the compilation, so typically a full node (compute or np)
the waiting mechanism is home-made and sometimes misses some fails - it could be improved
in particular cases, one could want to re-run the compilation without re-creating/populating the pack - separating them in 2 jobs would enable to achieve that

Propositions:

the gitref2pack loop could be run in a separate job, and interactively (not in batch)
the pack2bin loop job could be run in a compute/np job, in batch, using more threads (64)
the waiting mechanism to be revised
keep these 2 steps in the davai-build (in a shell scripts with 2 mkjobs call, cf. davai-ciboulai-init), but also create a separate davai-pack2bin command

ACCORD-NWP / DAVAI-tests

Dissociate git2pack & pack2bin into 2 jobs #31