ENH: Consider non-primitive data types

[tangkong]

Expected Behavior

Atef should be able to handle non-primitive (not int, float, bool, or str) data types for both passive and active checkouts.

• Passive checkouts should allow checking values in data such as arrays
• Active checkouts should support setting, say, lists to a PV

Current Behavior

Target and its subclasses used in SetValueStep expect only PrimitiveType. All Value subclasses expect their value field to be a PrimitiveType

This assumption is reflected in our GUI, which only really has simple LineEdits and SpinBoxes for input widgets

Possible Solution

🤔 Expanding the existing dataclasses to handle more complex data types will probably require some more involved logic in comparison. QDataclassBridges will also need to be updated to handle a potential Union[List[Any], PrimitiveType]

Obviously our GUI framework will have to extend as well, a natural list input widget will need to developed and applied more programatically

Context

Brought up in #159

Your Environment

pcds-5.7.1

[klauer]

For passive checkouts, our initial pass could be summarized as: "you must reduce your array data into a scalar to be able to compare [it and use it in a passive check]"

Is that still a reasonable approach for passive checks? I think it's worth discussing.

For active checks, it's not unreasonable to put an array (e.g., of calibration coefficients or something) and verify that they get set properly.