Summary of changes:
- fix MAC indentation
- bug fixes:
  - fix uplink over-scheduling
  - fix CQI updating (it was done even when it shouldn't)
  - fix rrc rel10 compilation
  - some minor bug fixes related to ASN.1

'_' is not a valid character.

S1AP specs say:

    ENBname ::= PrintableString (SIZE (1..150,...))

And X.680 (08/2015) 41.4 table 10 lists the valid characters for
PrintableString. '_' is not there. We replace by '-' which is there.

Connection of eNB to ppenair-cn has not been tested. There is no reason
why it would fail.

Conflicts:
	openair2/LAYER2/MAC/eNB_scheduler_primitives.c

Conflicts:
	openair2/LAYER2/MAC/eNB_scheduler_primitives.c
	openair2/LAYER2/MAC/eNB_scheduler_ulsch.c

Merge remote-tracking branch 'origin/fix-rrc-rel10-compilation-2018-w06' into develop_integration_2018_w06

Conflicts:
	openair2/LAYER2/MAC/eNB_scheduler_RA.c
	openair2/LAYER2/MAC/eNB_scheduler_primitives.c

The unused bits are the lower bits, so we need to shift.

Not sure that the value 1 is what we want though.

The problem that may happen is that when the UE does not transmit
on PUCCH (for whatever reason) we may get no signal at all, and
thus compute a very low CQI. Later on we may ask the UE to transmit
louder which may lead to saturation and more problems.

The solution is simple: don't care about CQI in case of DTX
(and NACK also, as done for PUSCH).

Only FDD case done.
For TDD it seems that:
- nfapi structures are not correct. See nfapi_harq_indication_tdd_rel13_t
  in nfapi/open-nFAPI/nfapi/public_inc/nfapi_interface.h, all the cases
  (bundling, multiplex, ...) use nfapi_harq_indication_tdd_harq_data_t
- the function extract_harq does not handle TDD

There is too much UL scheduling because the buffer status is
overestimated.

This commit tries to make things simpler.

The following compilation did not work anymore:

    ./build_oai --eNB -w USRP -r Rel10 -c

(Rel8 still does not work.)

S1AP specs say:

    initialUEMessage S1AP-ELEMENTARY-PROCEDURE ::= {
        INITIATING MESSAGE      InitialUEMessage
        PROCEDURE CODE          id-initialUEMessage
        CRITICALITY             ignore
    }

So let's use "ignore", not "reject".

The online decoder http://asn1-playground.oss.com/ did
not decode a message encoded by the eNB because of this.

Only the S1AP messages captured while doing a simple connection
of one UE have been tested with the online decoder.

So, not all the S1AP messages have been checked, maybe some
instances of this problem are still there.

It does not seem to harm the actual UE<->eNB<->EPC communication
(because we don't check the integrity of messages or because
asn1c does not do it), so it's not a big deal.