This commit follows the previous one and adds a dependancy for the
generated .h files so that when we change T_messages.txt to add a
T trace, the compilation succeeds when using ninja in
cmake_targets/ran_build/build.

When using the make system to generate T files, if you change
T_messages.txt you may have problems compiling the gnb with ninja.

If you want to see the problem:
First run: cd cmake_targets; ./build_oai --ninja --gNB
Then: cd common/utils/T
edit T_messages.txt, add a trace, for example:
---
ID = ENB_PHY_UL_TOCK
    DESC = eNodeB uplink tick - one tick per ms at start of uplink processing
    GROUP = ALL:PHY:GRAPHIC:ENB
    FORMAT = int,eNB_ID : int,frame : int,subframe
---
then run: make
then: cd cmake_targets/ran_build/build; ninja nr-softmodem
You should have an error looking like this:
---
[3/81] Checking validity of VCD files
FAILED: common/utils/T/CMakeFiles/check_vcd /tmp/develop/cmake_targets/ran_build/build/common/utils/T/CMakeFiles/check_vcd
cd /tmp/develop/cmake_targets/ran_build/build/common/utils/T && /tmp/develop/cmake_targets/ran_build/build/common/utils/T/_check_vcd /tmp/develop/common/utils/T/T_messages.txt /tmp/develop/common/utils/T/../LOG/vcd_signal_dumper.h
error: VCD_FIRST_VARIABLE is not correct in T_defs.h

You probably added a VCD trace (variable or function) but you did not
update T_messages.txt and/or T_defs.h in common/utils/T/
[...]
---

Let's first isolate the generated T .h files when using make because
we have two versions of T_IDs.h and T_messages.txt.h when mixing
make/cmake.

A next commit will regenerate T_IDs.h and T_messages.txt.h when
T_messages.txt chages for the cmake system, because this commit
does not solve the problem.

integration_2023_w43

See merge request oai/openairinterface5g!2415

* !2407 hotfix: UE DCI format 11: only 1 dl_config instead of 2
* !2372 chore(ci): testing up to 10 UEs in 5G RF simulation
* !2396 Add optimized function to count the number of bits set in uint64_t variable
* !2383 E1: implement release bearer, handle multiple CU-UPs
* !2413 Assigned value is garbage or undefined reported by scan-build
* !2387 Small fixes for UE stability and introduction of ITTI "no-thread" mode (separate bug fixes and ITTI changes?)
* !2410 Fix CellGroupConfig-related memory problems
* !2414 fix doxygen

Merge remote-tracking branch 'origin/assigned_value_is_garbage_or_undefined' into integration_2023_w43

- Set the correct QoS flow ID to associate a correct QoS flow to the
  bearer: the UE would misassociate otherwise
- Set the DRB as the default: the handler applies bool with true==1, so
  use bool value

Introduce a --no-itti-threads command line option to disable threading
in ITTI, and call message handlers in the current thread. This is being
introduced in order to increase repeatability when testing the nrUE with
the IQPlayer. Without this feature, runs with the IQPlayer will end up
differently, depending on the timing of ITTI threads, mostly when
sending messages to RRC and NAS.

Messages are pushed using pushNotifiedFIFO(), so we pullNotifiedFIFO()

Before this commit, the DMRS_UplinkConfig was stored in a separate
DMRS-related structure, although it is always referenced in the
PUSCHConfig of the current UL BWP.

Through certain code paths (e.g., retransmission), it could happen that
an old DMRS_UplinkConfig was accessed that was freed (through new
CellGroupConfig).

In this commit, we always look up the DMRS_UplinkConfig in the current
PUSCH config, which should always be up to date.

Until this commit, the SIB1's PDCCH_configCommon was set (via a pointer,
i.e., an indirection) to the one of the ServingCellConfigCommon (SCC).
Afterwards, the SIB1 code further populated this PDCCH configCommon,
indirectly populating the one of the the SCC, on which code later
depends.

Not only did this create possibilities for double-frees (since freeing
the memory of SIB1, then SCC would free the PDCCH configcommon twice),
but also it makes it harder to track where certain structures are
populated. Hence, this commit solves both issues:

- The SCC is correctly populated on initialization of the SCC
- The SIB1 makes a deep copy of the SCC' PDCCH configCommon

This resolves the two issues above.

Not initalizing this struct makes asn1c free the memory incorrectly,
leading to a segfault.

- harmonize monolithic and E1AP case
- use ITTI message to send bearer context setup response to RRC