- fix the run_enb_ue_virt_s1 script
  - change the Ki value back to the one used

Merge branch 'feature-34-test_framework' of https://gitlab.eurecom.fr/oai/openairinterface5g into feature-34-test_framework

The distinction common space/user space still requires some
careful examination.

T

I did some compilation tests using `./build_oai -s --run-group "0101*"`, all was fine.

I ran `lte-softmodem` with the sequans and let it run for a while with both
uplink and downlink UDP low throughput traffic, all was fine.

I ran some TCP tests, downlink 14 Mb/s (because the sequans does not report
a CQI of 15 but 14 maximum, so we don't go to maximum MCS, so 14 Mb/s instead
of 16) with a very clean radio (almost no error in the HARQ processes).

For uplink things are not so clean, it starts at 6 Mb/s and after a while goes
down to 2/3 Mbit/s. Lot's of errors in the HARQ processes, mostly uplink but
also downlink.

This is a both with and without T activated.

So to me it's fine.

The T tracer is a debugging tool. When it's not enabled,
it has zero impact on the processing. I think we need to
do very little tests before merging. I'll let you decide
but to me it's okay!

See merge request !36

if you compile *without* T it fails because the T macro is interpreted
as a function call

Conflicts:
	cmake_targets/CMakeLists.txt
	cmake_targets/build_oai
	openair1/PHY/LTE_TRANSPORT/pucch.c
	openair1/SCHED/phy_procedures_lte_eNb.c
	openair2/LAYER2/MAC/eNB_scheduler_ulsch.c
	targets/RT/USER/lte-softmodem.c

very basic, to be refined, find a nice way to display (plot? text?)
protocol data movement

to be refined, it's rough

3 pixels wide look better than 1

- update T_messages.txt
- update call sites of the T for thoses traces

more readable, still not satisfying though