BUG: fix issue with duplicate entries in pydaq controls

[ZLLentz]

Description

We have a wrapper here that automatically collects some arguments to fill into the per-scan daq configuration, including a list of devices whose positions we want to include in the daq data stream called the "controls" parameter.

This removes the check for adding "staged" devices to the daq controls list, instead only including devices that we "set" (move) before the first reading.

Motivation and Context

There is currently an issue where passing in a PseudoSingle as a movable to one of these daq-wrapped plans causes both the parent and child devices to be configured as the "controls" to include in the daq data stream, because the parent device is staged and the child device is set, and we were previously checking both of these cases for determining what goes into the data stream.

Using "stage" was done as a measure to include as many relevant devices as possible, but clearly it is including too many things.

With the assumption that all devices we care about are moved before the first reading, this should always give us the correct list of controls to automatically pass to the LCLS1 DAQ.

Previously, we were not making this assumption, and trying to catch a case where the user stages a motor but doesn't move it until much later. I think this case is rare, if it exists at all.

closes #43

How Has This Been Tested?

• Tried all of the currently available 1d "daq" scans just to check that they behave as I expect (set before trigger)
• Added a pseudomotor test case that would have failed prior to the change

Where Has This Been Documented?

Pre-release notes

Pre-merge checklist

• [x] Code works interactively
• [x] Code contains descriptive docstrings, including context and API
• [x] New/changed functions and methods are covered in the test suite where possible
• [x] Test suite passes locally
• [x] Test suite passes on travis
• [x] Ran docs/pre-release-notes.sh and created a pre-release documentation page
• [x] Pre-release docs include context, functional descriptions, and contributors as appropriate

[ZLLentz]

Here are the messages from the beginning of a representative scan that previously had the issue. Note the set message that catches our positioner, the stage message that used to catch the parent device, and no duplications in the daq configure message.

In [5]: list(bp.daq_ascan([], fake_ccm.E, 7, 8, 5, events=120, record=False))
Out[5]:
[Msg('stage', obj=<pcdsdaq.daq.Daq object at 0x7f025e6bba00>, args=(), kwargs={}, run=None),
 Msg('stage', obj=FakeCCMEnergy(ALIO, name=fake_ccm_energy), args=(), kwargs={}, run=None),
 Msg('open_run', obj=None, args=(), kwargs={'detectors': [], 'motors': ('fake_ccm_energy_energy',), 'num_points': 5, 'num_intervals': 4, 'plan_args': {'detectors': [], 'num': 5, 'args': ['FakePseudoSingleInterface(ALIO:energy, name=fake_ccm_energy_energy)', 7, 8], 'per_step': 'None'}, 'plan_name': 'scan', 'hints': {'dimensions': [(['fake_ccmE'], 'primary')]}, 'plan_pattern': 'inner_product', 'plan_pattern_module': 'bluesky.plan_patterns', 'plan_pattern_args': {'num': 5, 'args': ['FakePseudoSingleInterface(ALIO:energy, name=fake_ccm_energy_energy)', 7, 8]}}, run=None),
 Msg('checkpoint', obj=None, args=(), kwargs={}, run=None),
 Msg('set', obj=FakePseudoSingleInterface(ALIO:energy, name=fake_ccm_energy_energy), args=(7.0,), kwargs={'group': 'set-f7b563'}, run=None),
 Msg('wait', obj=None, args=(), kwargs={'group': 'set-f7b563'}, run=None),
 Msg('configure', obj=<pcdsdaq.daq.Daq object at 0x7f025e6bba00>, args=(), kwargs={'events': 120, 'duration': None, 'record': False, 'use_l3t': False, 'controls': [FakePseudoSingleInterface(ALIO:energy, name=fake_ccm_energy_energy)]}, run=None),

Unrelated: I definitely didn't get the "name" correct for the scans/tables that the scientists want to do- my name aliasing has failed. I'll need to revisit this in a pcdsdevices PR.