Reporting PO types

[gtfierro]

Would like to standardize on a subset of PO types used for reporting data

[gtfierro]

The necessary fields here are the value being published, and also the time that value was published. Generating the timestamp on the device side allows for the alignment of multiple fields. For example, a relative humidity reading is valid at a given temperature; if the device measures both simultaneously, then this should be reflected in the reported messages.

For reporting values, I suggest something like the following

{
    Value: <numerical value>,
    Time: <unix nanosecond timestamp>
}

The numerical value is likely to be a 64-bit float, though whatever serialization format we use for the message will be able to account for signed/unsigned integer values as well.

This should work fine for numerical data; for non-numerical data, we can have a separate discussion.

Regarding the serialization format, I think msgpack works fine as a default. The only real alternative to consider in the context of devices we work with in XBOS is JSON, and this structure is compatible there too. We can just define a "timeseries" payload object type for each serialization format

[gtfierro]

This also involves #18

So, keeping in with the discussion at #1 we are publishing structs of values on signals and slots (see driver conventions documentation).

As a result, we will likely have one PO type per interface, with the signals and slots refining which "properties" (the allowed keys/values in the structs) are permitted on those endpoints. This gives us a uniformity over the device (avoiding the "which PO type do I use for actuation on this slot vs the other slot?" question), while still giving us room for making the interface more modular for purposes of fine-grained permissions.