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"