implement IIC resource/sequence manager

IIC current sequencing design was mostly adapted from spsaitActor.
It has not been optimized to handle multiple subsystems and with the new hardware coming to the summit fairly soon (SuNSS, SM2 ...)
We need an upgrade which would be a step forward in terms of flexibility and reliability.
There is an early design document here

I'm copying some slack discussions from cloomis :

With the arrival of SuNSS, we have a couple of operational (ICS and DRP) questions to address. In particular: will we want to run, or even configure, any combination of DCB, SuNSS, and “normal SPS” SMs at the same time?
If we do (and I think we will — imagine having SuNSS plugged into SM1, stability/calibration acquisitions on SM2, and DCB on the nWith the arrival of SuNSS, we have a couple of operational (ICS and DRP) questions to address. In particular: will we want to run, or even configure, any combination of DCB, SuNSS, and “normal SPS” SMs at the same time?
If we do (and I think we will — imagine having SuNSS plugged into SM1, stability/calibration acquisitions on SM2, and DCB on the newly commissioned SM3), how should we deal with it? What changes would we need to make?
As it currently stands for ICS, spsActor is written to abstract away the individual modules and cameras, and iic currently only controls a single “sps”.
Taking single SPS exposures with differently configured SMs seems like undesirable madness, but being able to easily take SPS exposures from the different SMs independently has to be worthwhile trying to do. The currently proposed mechanism of declaring to IIC where the light is coming would need to be fleshed out to optionally declaring where the light for each SM is coming from. And both sps and iic would need to be able to cleanly control sets of SMs in addition to the default entire PFI.
I propose the following changes:

• change the iic light source configuration to be per-SM (or by default full-PFI)
• add DCBx targetTypes, like in DAMD-91. Need to think about abusing ra/dec or adding (part of) the targetType to the SHA?
• change the pfsDesign and designId to always be built from the full 2394+ fiber design, using the DCB and SuNSS fiber assignments. We could swap the active designs between visits but that makes me very nervous.
• Allow spsActor to concurrently control multiple SMs,
• Add iic expose knobs to optionally select SMs to acquire from.ewly commissioned SM3), how should we deal with it? What changes would we need to make?
  As it currently stands for ICS, spsActor is written to abstract away the individual modules and cameras, and iic currently only controls a single “sps”.
  Taking single SPS exposures with differently configured SMs seems like undesirable madness, but being able to easily take SPS exposures from the different SMs independently has to be worthwhile trying to do. The currently proposed mechanism of declaring to IIC where the light is coming would need to be fleshed out to optionally declaring where the light for each SM is coming from. And both sps and iic would need to be able to cleanly control sets of SMs in addition to the default entire PFI.
  I propose the following changes:
• change the iic light source configuration to be per-SM (or by default full-PFI)
• add DCBx targetTypes, like in DAMD-91. Need to think about abusing ra/dec or adding (part of) the targetType to the SHA?
• change the pfsDesign and designId to always be built from the full 2394+ fiber design, using the DCB and SuNSS fiber assignments. We could swap the active designs between visits but that makes me very nervous.
• Allow spsActor to concurrently control multiple SMs,
• Add iic expose knobs to optionally select SMs to acquire from.