Explicit toRos_INTEGER(const long&, int64_t&)

[v0-e]

Calls to toRos_INTEGER() when T is long/int64_t are ambiguous due to two conflicting overloads:

void toRos_INTEGER(const T& _INTEGER_in, int64_t& INTEGER_out);

and

void toRos_INTEGER(const long& _INTEGER_in, T& INTEGER_out);

This PR simply adds an explicit toRos_INTEGER() overload for (const long&, int64_t&).

[lreiher]

Where are you calling those from / why do you need that overload?

[v0-e]

The issue appears when there is INTEGER ASN.1 definition represented by a ROS int64.
For example, imagine if AltitudeValue was represented by an int64 instead of an int32. When compiling the conversion headers, the compiler does not know which toRos_INTEGER() variant to call.
While allowed, it wrongly considers the first variant, which should only take asn1c's INTEGER_t as first argument given the use of asn_INTEGER2long(const INTEGER_t*, long*) in it. The compiler considers the first variant because it does not know that the templated type T should only be INTEGER_t. To not add an include for INTEGER_t in convertINTEGER.h, I just introduced the additional overload solution instead of the removing the template.

While all (or most?) current ETSI ITS integer types can be represented by an int32/uint32, I was considering using int64 to represent some ASN.1 INTEGER definitions which are extensible like this this. An extensible ASN.1INTEGER definition allows for future, updated, constraints, allowing it to take any value depending on the version of the definition.
I'm not sure if this compatibility is desired for now, however this overload can still make sense in other scenarios.