Ensure 4 byte property values don't use int, for 16 byte builds

[icraggs]

See the report in #1493:

On the Paho C++ repo, someone just pointed out that the 2 and 4-byte integer property values are defined to always be unsigned. (According to the v5 spec). eclipse-paho/paho.mqtt.cpp#498 .

Somehow the "always unsigned" part escaped me these last few years.

In this C library it is coded correctly in the enum inside MQTTProperty, but the retrieval functions return an int, which is 32-bits on most modern PC compilers.

/**

• Returns the integer value of a specific property. The property given must be a numeric type.
• ...
• @return the integer value of the property. -9999999 on failure.
  */
  LIBMQTT_API int MQTTProperties_getNumericValue(MQTTProperties *props, enum MQTTPropertyCodes propid);

/**

• Returns the integer value of a specific property when it's not the only instance.
• ...
• @return the integer value of the property. -9999999 on failure.
  */
  LIBMQTT_API int MQTTProperties_getNumericValueAt(MQTTProperties *props, enum MQTTPropertyCodes propid, int index);

This means that larger 4-byte values will be misinterpreted as negative numbers, which is kinda bad. But it also means that the "error" return value of -9999999 falls well within the range of valid possible values, and in fact, any 32-bit int value could be valid.