Add Acquisition or Configuration category to public properties

[bparks13]

To ensure a consistent user experience across all operators, this PR adds a string to the Category attribute for all public properties that defines the property as Acquisition, Configuration, or Devices.

Configuration properties are set prior to the start of the workflow. These are not updated in real-time, and are configured once when the workflow starts.

Acquisition properties can have an initial state defined before the workflow begins, but they can be updated in real-time with new values sent to hardware while the workflow is running.

Devices properties are only applicable for aggregates, where this category is applied to each device in an aggregate.

[jonnew]

Can you do a quick review of all these changes and make sure that they comport with my commands on MutliDeviceFactory.Name? Basically, a property should be marked if its something exposed to the user that changes the behavior of a device at start or start/runtime. Anything outside of that scope should not be marked.

Aside from this, in ConfigureBreakoutAnalogIO the direction properties are all marked as Acquisition, but should be configuration. Thats left over from when they were settable at runtime and I forgot to change.

[jonnew]

The remaining thought I have before merging is the members of a MultiDeviceFactory being marked as Configuration

I understand the reasoning here, as the properties referred to by the attribute are indeed Configuration level. But really the user is going to be manipulating the inner properties of the devices, which can be both Acquisition or Configuration. These are not shown in the current property pane, but the point kinda still stands.

I think a way around this to define another category defintion

public abstract class DeviceFactory : Sink<ContextTask>
{
    internal const string ConfigurationCategory = "Configuration";
    internal const string AcquisitionCategory = "Acquisition";
    internal const string DevicesCategory = "Devices";

    internal abstract IEnumerable<IDeviceConfiguration> GetDevices();
}

which can be used for member devices of MultiDeviceFactorys

The Devices name is up for suggestions.

[bparks13]

I am in favor of adding Devices as a category, I was just looking at the docs to see how we refer to these; they are classified as Device Configuration Operators, and we refer to them as devices from the aggregate level.

My only caveat with adding this category is that @cjsha and I were discussing what to name the headings in the aggregate page (for instance, ConfigureBreakoutBoard). Currently they are listed as Properties, but if we add this new category I would argue that we change the heading to match it, since the subheadings are the devices.

[jonnew]

@bparks13 I agree with all. I feel a small force against this because in the ONI standard, device has very particular meaning. However, the ONI standard does not get to uniformly define what a device is for all its possible uses. In the context of this library, its very useful to refer to these leaf objects as devices, so let's do that (here and in the docs).