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"