Information object set RANAP-ELEMENTARY-PROCEDURES is a union of
RANAP-ELEMENTARY-PROCEDURES-CLASS-1 and RANAP-ELEMENTARY-PROCEDURES-CLASS-2.

Each time _asn1f_assign_cell_value() parses an object, value of an
incremented counter is assigned to '_type_unique_index' field for
distinquishing different items.

However, these two information object sets have their own counters.
It has chance that generated variables have the same name and also the same
'_type_unique_index'. And they collide if they join up into one set.

S1AP's ASN.1 is lucky without this problem, while RANAP has.

By adding the number of items of the first set to '_type_unique_index' field
of items of the second set can solve this issue.

There will be two selector functions generated for the following ASN.1 excerpt.

InitiatingMessage ::= SEQUENCE {
    procedureCode S1AP-ELEMENTARY-PROCEDURE.&procedureCode     ({S1AP-ELEMENTARY-PROCEDURES}),
    criticality   S1AP-ELEMENTARY-PROCEDURE.&criticality       ({S1AP-ELEMENTARY-PROCEDURES}{@procedureCode}),
    value         S1AP-ELEMENTARY-PROCEDURE.&InitiatingMessage ({S1AP-ELEMENTARY-PROCEDURES}{@procedureCode})
}

This pull request enables different function names by adding field name after type name.

For example, there are many 'enum value_PR' and 'struct value' generated if
a class is instantiated as many instances.

typedef enum value_PR {
    value_PR_NOTHING,    /* No components present */
    .....
} value_PR;

typedef struct ProtocolIE_Field_6563P5 {
    ....
    struct value {
        value_PR present;
        union value_u {
        } choice;

        /* Context for parsing across buffer boundaries */
        asn_struct_ctx_t _asn_ctx;
    } value;

    /* Context for parsing across buffer boundaries */
    asn_struct_ctx_t _asn_ctx;
} ProtocolIE_Field_6563P5_t;

E-RABToBeSetupItemBearerSUReqIEs S1AP-PROTOCOL-IES ::= {
    { ID id-E-RABToBeSetupItemBearerSUReq   CRITICALITY reject	TYPE E-RABToBeSetupItemBearerSUReq	PRESENCE mandatory },
    ...
}

result in 'FATAL: Information Object Set E-RABToBeSetupItemBearerSUReqIEs contains no objects at line xxxx'

If it contains more than one entry then there is no problem.

E-RABSetupRequestIEs S1AP-PROTOCOL-IES ::= {
    { ID id-MME-UE-S1AP-ID                  CRITICALITY reject  TYPE MME-UE-S1AP-ID                     PRESENCE mandatory }|
    { ID id-eNB-UE-S1AP-ID                  CRITICALITY reject  TYPE ENB-UE-S1AP-ID                     PRESENCE mandatory }|
    { ID id-uEaggregateMaximumBitrate       CRITICALITY reject  TYPE UEAggregateMaximumBitrate          PRESENCE optional  }|
    { ID id-E-RABToBeSetupListBearerSUReq   CRITICALITY reject  TYPE E-RABToBeSetupListBearerSUReq      PRESENCE mandatory },
    ...
}

One of the most tricky ASN.1 excerpt :

E-RABDataForwardingItemIEs S1AP-PROTOCOL-IES ::= {
    { ID id-E-RABDataForwardingItem   CRITICALITY ignore   TYPE E-RABDataForwardingItem PRESENCE mandatory },
    ...
}

E-RABSubjecttoDataForwardingList ::= E-RAB-IE-ContainerList { {E-RABDataForwardingItemIEs} }

E-RAB-IE-ContainerList { S1AP-PROTOCOL-IES : IEsSetParam } ::=
    ProtocolIE-ContainerList { 1, maxnoofE-RABs, {IEsSetParam} }

ProtocolIE-ContainerList {INTEGER : lowerBound, INTEGER : upperBound, S1AP-PROTOCOL-IES : IEsSetParam} ::=
    SEQUENCE (SIZE (lowerBound..upperBound)) OF
    ProtocolIE-SingleContainer {{IEsSetParam}}

ProtocolIE-SingleContainer {S1AP-PROTOCOL-IES : IEsSetParam} ::=
    ProtocolIE-Field {{IEsSetParam}}

ProtocolIE-Field {S1AP-PROTOCOL-IES : IEsSetParam} ::= SEQUENCE {
    id          S1AP-PROTOCOL-IES.&id           ({IEsSetParam}),
    criticality S1AP-PROTOCOL-IES.&criticality  ({IEsSetParam}{@id}),
    value       S1AP-PROTOCOL-IES.&Value        ({IEsSetParam}{@id})
}

Fix 'FATAL: Does not look like criticality is a CLASS field reference (xxxx) denoting a type one line xxx'

In Module_1,

	Criticality ::= ENUMERATED { reject, ignore, notify }

In Module_2,

	IMPORTS
		Criticality
	FROM Module_1

		someMessage SOME-CLASS ::= {
			CRITICALITY	ignore
		}

This pull request add the capability to resolve 'reject', 'ignore' and 'notify'
in Module_2.

The aforementioned error message displayed during processing the following ASN.1 excerpt.

S1AP-ELEMENTARY-PROCEDURES S1AP-ELEMENTARY-PROCEDURE ::= {
    S1AP-ELEMENTARY-PROCEDURES-CLASS-1 |
    S1AP-ELEMENTARY-PROCEDURES-CLASS-2,
    ...
}

S1AP-ELEMENTARY-PROCEDURES-CLASS-1 S1AP-ELEMENTARY-PROCEDURE ::= {
    handoverPreparation                |
...
    writeReplaceWarning,
    ...,
    uERadioCapabilityMatch             |
....
    uEContextResume
}

S1AP-ELEMENTARY-PROCEDURES-CLASS-2 S1AP-ELEMENTARY-PROCEDURE ::= {
    handoverNotification               |
...
    privateMessage,
    ...,
    downlinkUEAssociatedLPPaTransport  |
...
    mMECPRelocationIndication
}

Because S1AP-ELEMENTARY-PROCEDURES-CLASS-1 and S1AP-ELEMENTARY-PROCEDURES-CLASS-2
are resolved 'after' S1AP-ELEMENTARY-PROCEDURES, so the ioc tables of them are not
available during resolving S1AP-ELEMENTARY-PROCEDURES. So we can not drop the
latter's containedSubtype field at first pass of asn1f_resolve_constraints of fix
process.

We also add second pass of asn1f_resolve_constraints to have a chance to combine
ioc tables of S1AP-ELEMENTARY-PROCEDURES-CLASS-1 and
S1AP-ELEMENTARY-PROCEDURES-CLASS-2.