Redesign device `properties` handling

[cfobel]

Current behaviour

Currently, each of the following properties MUST exist as a method on the proxy class that returns a np.array:

• 'base_node_software_version'
• 'package_name'
• 'display_name'
• 'manufacturer'
• 'url'
• 'software_version'
• 'hardware_version'
• 'id'
• 'uuid'

The properties attribute is defined as a Python property that calls each of the methods (if they exist as attributes) and combines the results into a pandas.Series.

See also #6.

Reasoning behind current behaviour

Part of the reason why the above device properties are combined into a properties attribute is that the methods are returning np.array instances which must be converted to strings using the np.array.tostring() method. This is because the only supported way to return a string at the moment is by casting it as the data attribute of a UInt8Array in the C++ firmware.

The properties attribute was introduced to make things a bit easier, while explicitly defining the subset of methods to be queried as device properties. However, this behaviour is not very intuitive and is a bit clunky.

[cfobel]

Proposed behaviour

As part of this new project, more information about the class members is available during code generation. This includes:

• Names of all class members (both methods and attributes, i.e., member variables)
• Access specifier for each member (e.g., public, protected, private)
• Member const-ness

One way to handle the concept of properties given this information is to map any public C++ member that is defined as const (either attribute or method) to a read-only Python property.

Advantages

• No need to explicitly define list of device properties in Python code.
• If C++ attribute type is a constant char array (i.e., with known size), a string can be returned automatically (this can differentiate from the UInt8Array handling).
• Can support other types as well (not just strings).