Revisit Branching

[ZLLentz]

Expected Behavior

Branching should be simple and consistent to configure, determined before runtime, and be able to handle cases of multiple inputs and multiple outputs.

Current Behavior

Branching is configured differently on different devices and cannot handle multiple input paths. In general, branching information is retrieved from the device at runtime through the attributes: .branches for a list of possible output beamlines .destination for the current output beamlines

Possible Solution

Another off-the-cuff API suggestion (coupled with #106):

• Configure lightpath_outputs list ahead of time for branching devices (in happi) to enumerate where the beam can go.
• Have the device return a tuple of beam parameter dicts if it has multiple outputs
• Configure lightpath_inputs list ahead of time for devices with multiple inputs (in happi) to enumerate which sources go to which input.
• Have the device expect a tuple of beam parameter dicts if it has multiple inputs

Context

LCLS2 will have two sources that can go to either line. LCLS1's XCS LODCM already has two inputs.

[klauer]

Also sounds good - though going toward named inputs/outputs as in #106 would be my preference, if possible.

[ZLLentz]

I think named inputs and outputs is a clear winner here :+1:

[tangkong]

Closed by #133 , and the eventual https://github.com/pcdshub/pcdsdevices/pull/1028