When ActualParameter to a parameterized type is a Type, commit
59b9e705 will produce C struct types using ActualParameter,
which are conflict with the C struct types for these Types themselves.

For example, the following typedef has duplicate definition of
UCI_OnPUSCH_t :

typedef struct UCI_OnPUSCH {
	UCI_OnPUSCH_PR present;
	union UCI_OnPUSCH_u {
		NULL_t	 release;
		UCI_OnPUSCH_t	 setup;
	} choice;

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

With this commit, if ActualParameter is a Type, then prefix it
with Parameterized Type name.

typedef struct SetupRelease_UCI_OnPUSCH {
	SetupRelease_UCI_OnPUSCH_PR present;
	union SetupRelease_UCI_OnPUSCH_u {
		NULL_t	 release;
		UCI_OnPUSCH_t	 setup;
	} choice;

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

As for ActualParameter is ObjectSet, used in S1AP ... etc, it doesn't
prefix generated typedefs for keeping names shorter.

This commit can replace item 3 of

https://github.com/vlm/asn1c/issues/282#issuecomment-390838895

which solve part of #282.

1. Record the de-referenced expression to newly added field ref_expr
   of strcut asn1p_ref_t.
2. In function asn1c_make_identifier(), not only check whehter there
   is name clash occurred for this asn1p_expr_t but also the referenced
   expression to determine whether an additional module name to be added.
3. Change signature of some functions and variables to eliminate warning
   messages when const type pointer, i.e. const asn1p_ref_t *, variables
   versus, non-const * type pointer, i.e. asn1p_ref_t *, varibles are
   used. E.g.:
   warning: assignment discards ‘const’ qualifier from pointer target type

Recent commit abd1faa6 broke passing
already existing output decoded structre as sptr. As a result, a new
sptr was always allocated, and the old one leaked.

Fixes: abd1faa6

Should close #98

This should help aper_put_length() to take proper decisions on the way
to encode the length, since the range alone is not enough.
A contraint of lb=1 ub=65536 would yield a range=65536, but according to
ITU-T X.691 11.9 it shouldn't be encoded using nsnnwn since that only
applies in case ub<65536.
As a result, it would end up encoding/decoding it using 2 bytes while it
should use only 1.

Related: https://github.com/mouse07410/asn1c/issues/94

This should help aper_put_length() to take proper decisions on the way
to encode the length, since the range alone is not enough.
A contraint of lb=1 ub=65536 would yield a range=65536, but according to
ITU-T X.691 11.9 it shouldn't be encoded using nsnnwn since that only
applies in case ub<65536.
As a result, it would end up encoding/decoding it using 2 bytes while it
should use only 1.

Related: https://github.com/mouse07410/asn1c/issues/94

the code is in a version control system for this kind of reasons.

Fixed as seen the function is being called in most placed where
need_eom is true.

What's seems to be newish available ITU-T X.691 (02/2021),
has the related section at 11.9, not 10.9.

Drop spacing and use tabs everywhere.

This also fixes a gcc warning about "if" clause not guarding code below
it.

Fixes bug introduced in 0101252e [1].
This is actually mainly a revert of that commit.

That commit introduced a bug in which a small value (under 1 octet) with
range spanning full 2 octets (65536) was encoded incorrectly as 1 octet.

Section 4 of X.691 defines 64K as 65536, and Section 11.5.7 explicitly states
"""
c) "range" is greater than 256 and less than or equal to 64K (the two-octet case).
"""

This was noted while encoding SBc-AP messaged generated with asn1c,
where a SEQUENCE OF uses aper_put_length() to set the number of items.

[1] https://github.com/mouse07410/asn1c/pull/91

This commit adds a test case which shows a bug introduced in
0101252e [1].

As a result, a small value (under 1 octet) with range spanning full 2
octets (65536) is encoded incorrectly as 1 octet.

Section 4 of X.691 defines 64K as 65536, and Section 11.5.7 explicitly states
"""
c) "range" is greater than 256 and less than or equal to 64K (the two-octet case).
"""

[1] https://github.com/mouse07410/asn1c/pull/91

This patch introduces a test uncovering a bug when tyring to use
aper_put_length() with a value bigger than its range.
A follow up commit fixes the bug.

aper_put_length is expected to return the length being written in other
code paths. In the nsnnwn path, it was returning only 0 or <0.

While the historic asn1c code base has always had unit tests for not
just the ASN.1 parser but also the encoding rules, this doesn't seem
to hold true for the APER support in the various forks.

Unfortunately this has proven troublesome as over time patches were
merged supposedly fixing corner cases while in reality breaking behavior
that was perfectly in-line with the spec (ITU-T X.691).

Let's start by at least add some very basic coverage for the INTEGER
type in APER.

Otherwise the fields end up being misplaced and crash during encoding,
as can be seen in gdb:
"aper_decoder = 0x7ffff7687616 <OPEN_TYPE_encode_aper>, aper_encoder = 0x0"