2. Fixing the arguments in the dump_dlsch2.

Conflicts:
	openair1/PHY/INIT/lte_init.c
	openair1/PHY/LTE_ESTIMATION/lte_ue_measurements.c
	openair1/PHY/LTE_TRANSPORT/dci_tools.c
	openair1/PHY/LTE_TRANSPORT/dlsch_demodulation.c
	openair1/PHY/LTE_TRANSPORT/dlsch_modulation.c
	openair1/PHY/LTE_TRANSPORT/proto.h
	openair1/PHY/MODULATION/slot_fep.c
	openair1/PHY/TOOLS/lte_phy_scope.c
	openair1/SCHED/phy_procedures_lte_eNb.c
	openair1/SIMULATION/LTE_PHY/dlsim.c

The old value was 6, it should be 8 because those fields are
casted to 'struct DCI0_5MHz_FDD' and the like and those have
a size multiple of 32 bits, that is 4 or 8 bytes as of today.

(MAX_DCI_SIZE_BITS is 45, all the shifts, muls and adds lead
to a value of 8 after this commit and 6 before.)

The problem manifested itself with a 20MHz eNB. Push the traffic,
after a while the DL harq process 0 is not used anymore.
This is because DLSCH_DCI is directly followed by nb_rb in
the structure UE_TEMPLATE and setting a value for harq process 7
did overwrite nb_rb[0], putting much too big values in there,
leading to the scheduler to always refuse to reschedule because
the required RBs are impossibly huge (I saw values of 32744, 16384,
and others).

The ExpressMIMO2 kernel driver did not use proper mechanisms
to copy from user space.

It is very surprising that it ever worked at all...

This commit is a quick fix. It is not the end of the story
and some more work may be needed if things don't work.

The remaining issue is that we pass pointer addresses to the
kernel as 32 bits values, but pointers are 64 bits values
(on x86_64, our supported platform). Some checks have been
put in place to detect if upper 32 bits of a pointer are
not 0 and print a strong error message in case of problem,
but no clean solution has been implemented.

Merge branch 'enhancement-10-harmony' of gitlab.eurecom.fr:oai/openairinterface5g into enhancement-10-harmony