In the UE, we wish to handle ^C in the UE to send a message before
terminating, so we allow custom wait handlers to implement such
functionality. Use itti_wait_tasks_unblock() to unblock
itti_wait_tasks_end().

Also, implement itti_wait_tasks_end() using semaphores, as signals are
not async-signal-safe (and therefore should not be used in a signal
handler).

integration_2023_w12

See merge request !2030

* !1957 UL improvements for 2-layers
* !2016 int32_t to c16_t conversion
* !2028 Fix ue capability config files
* !2022 NR dlsim pmi input
* !2027 limiting SR periodicity according to scs
* !1985 Correct F1 RRC Message Transfer
* !2024 harmonize mac_CellGroupConfig RRC configuration
* !2026 Fix build by installing nrscope dependencies

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Add CI test: 3GPP G-FR1-A4-27, PUSCH Type B, 40 MHz BW, 30 kHz SCS, 2 RX Antennas Requirements Test, 2 layers

The message is never sent to the RRC. And this message is to be
forwarded by the DU to the UE, hence it should not even be handled by
the RRC (as the RRC in the CU sends it).

The RRC container is transparent for the DU. Hence, we should not decode
it.

During the Initial UL RRC Message, the CellGroup is created. Since the
CellGroup specifies the SRB1, the SRB1 should also be created (because
the DL RRC Messages is sent via SRB1). However, before this commit, the
CellGroup is created while having the RLC lock, so we cannot create
SRB1, as it results in a deadlock.

Therefore, we now first create CellGroup, SRB0, and SRB1, before giving
the UE message to the RLC.