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

events are accepted by the logger if the filter accepts them
the filter is optional (no filter means to accept all events)

improve the use of the variable "frame" in oaisim

The modifications are only in oaisim.c.
It is thus needless to run soft-modem tests.
Only oaisim tests are required.

See merge request !34

this is like timeview but the plotting is done at frame/subframe
resolution of a given reference clock signal, let's say.

The realtime information of the events is not used. It's all
logical.

It will be used to log harq processes for the moment.

this may be removed at some point, it's very brutal. But when you
write some code, it may happen (it "may"!!) that *sometimes* the
code does not work and crashes. In thoses cases I prefer the
local tracer (or the tracee) to go away immediately without even
thinking about it maybe still running in the background.

In case of monitoring (as opposed to debugging) maybe it's preferable
to let the process live its life as it wants.

Time will tell.

and also start to use the PHY textview

always a good idea to crash in unknown situations...

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