Make caps parsing stricter

[Seizure]

Currently, the technical definition of a capabilities dictionary as defined by PYDDC allows for indefinitely deeply nested Capabilities, and also allows both feature codes, and their values, to be strings.

In reality, such cases (if they do exist somewhere) are meaningless/uninterpretable

A better solution would be to enforce feature codes and their discrete parameters (respectively, the keys and values, of the cmd and vcp entries in a caps dict) as ints. Similarly, the value(s) of a feature should be single values, and not another nested dictionary. If a violation of either expectation is found, just strip it out and put it in an errata section, or something.

This is a more pragmatic interpretation of (potentially invalid) caps data, and also makes it easier for client apps (such as monitorboss) to handle the data.

[Rangi42]

info.py now takes the dict that pyddc returns, and transforms it into a CapabilityData object. We want to make pyddc return such a CapabilityData object directly.

One catch: pyddc would have to use raw ints for things. So info.py/cli.py would still have to process those into FeatureData, ValueData.

[Rangi42]

Basically _parse_caps_dict should return an object of similar structure to CapabilityData, just with ints instead of value objects. Then transforming Capabilities to CapabiityData would be simpler (each int becomes a value object but structure stays the same), and we wouldn't have to support arbitrary nesting of key-value parenthesized stuff.

[Rangi42]

Remember to write test code (if we're not already testing caps parsing)! Check the code coverage report after refactoring.