Checking if data changed prior to Tx writes is not valid when multiple instances exist

[buckd]

Describe the bug
When multiple instances of the custom device are run on a single target, the data check for whether any values have changed prior to writing to the driver is invalid and may cause not all data to be written.

To Reproduce
Steps to reproduce the behavior:
This was discovered by inspection of the code while investigating AB#2721163. This is not the root cause of that escalation, but is a bug in the code that should be fixed.

Expected behavior
Each execution unit should have its own copy of the previous data to compare against the latest data.

Screenshots

This check stores data that can be accessed by any Tx execution unit, so it is not valid if there are multiple execution units executing.

Desktop (please complete the following information):

• Linux RT

Additional context
Change #206 modified the scheduled Tx execution unit to check if any values had changed before writing updates to the Ballard driver because the driver calls are slow and there is no point in writing the same data over and over. The problem is the previous data values are stored in a feedback node inside Write to Hardware.vi, which will be called by any scheduled Tx write execution unit. If there are multiple execution units (i.e. multiple cores with Tx writes) configured in the system definition under a single controller, this check will inevitably compare data from the current iteration of one execution with data from the previous iteration of a different execution unit, rendering the check invalid and possibly failing to write all data if the array sizes don't match.

There are likely 2 ways to implement this fix and keep the check. The first is to keep a copy of the previous data inside the execution unit class data, which isn't really desirable since the class really shouldn't need to know that. This solution may be the easiest and possibly the most performant to implement.

The second way would be to make a preallocated subVI that does the check and stores the data and force a new instance of that subVI to be opened during execution unit initialization, storing that VI ref in the class data, and calling it by reference in Write to Hardware.vi so each execution unit is sure to check its own previous data.