Add support for MQTT 5

[alexandruioanp]

This PR adds support for MQTT 5.0 (protocol level 5) as summarised here.

Most of these new features are implemented via Properties. A large part of this diff is comprised of code to handle the encoding and decoding of these properties. I was considering pulling out the property handling code to a separate set of files (mqtt-prop.c/h?)

EDIT:
See here for how to print properties using the mosquitto client. You should get something like this (see the properties field):

# mosquitto_sub  --verbose -t "#" -F %J -V 5

{"tst":1587821578,"topic":"iot-2/evt/status/fmt/json","qos":0,"retain":0,"payloadlen":93,"properties":{"user-properties":{"Contiki":"v4.5+"}},"payload":{"d":{"Platform":"native","Seq #":3,"Uptime (sec)":418,"Def Route":"fd00::1","RSSI (dBm)":0}}}

[g-oikonomou]

!

I was considering pulling out the property handling code to a separate set of files (mqtt-prop.c/h?)

Sounds like a reasonable idea. I see you have wrapped them around a cpp #if for conditional compilation - I don't think you need to necessarily do that, perhaps you can always compile and let the linker garbage collect those symbols.

I'm not sure why the diff is showing up with all those file renames.

[alexandruioanp]

Regarding the renames, I made some space for contiguous MQTT test numbering (02 through 07, though I see I missed 07-native-ping.sh).

The compiler was throwing errors for unused functions, so I had to wrap some of them in ifdefs, but I think it might be my container misbehaving.

[g-oikonomou]

The compiler was throwing errors for unused functions, so I had to wrap some of them in ifdefs, but I think it might be my container misbehaving.

Hmmm I this this will happen for unused static functions. But if you were to move them to a separate file and make them non-static it would go away.

[g-oikonomou]

Overall great work, just some bureaucracy I'm afraid Alex...

[g-oikonomou]

That's all fine, just need to get the macro/type/function names prefixed with the module name properly