Add support for moveable `SystemComponent`s

[EvanKirshenbaum]

I'm splitting the general notion of moveable SystemComponents off of the issue of supporting the ESELog fluorescence detector (#206).

My basic thought is that SystemComponents (either all of them, or those deriving from some MoveableComponent class) can have one or more Posistions, each of which has a Shadow cast on the System's Board. The Shadow knows its component and also contains a GridRegion of Pads the component covers in that Position. It knows whether it overlap()s another Shadow.

The System contains a set of reserved Shadows, a set of evictable Shadows, and a set of blocked Shadows. Before a component can move into position, it must reserve() the Position's Shadow. If this Shadow doesn't overlap any reserved or evictable shadows, it adds itself to the reserved set and signals its component that it's okay to move. Otherwise, if it overlaps any evictable shadows, it evicts their components. In any case (if there was overlap), it adds itself to the blocked set.

When a component is evicted, it moves to an off-Board position and then removes its old Position's shadow from the evictable set. I'm assuming for now that this can happen without worrying about interference from or to other moving components. If this is not the case, this will become a fair bit trickier. So, to start, let's assume that all components have a clear horizontal path off the board to an identified side.

Whenever a Shadow is removed from either the reserved or evictable sets, the blocked set is scanned to see if any Shadow is now clear. If so, it is moved to the reserved set and the component is told that it's okay to move. Note that this could result in starvation. I'm not going to worry about fairness at this point.

When a component is done needing its position, rather than moving away, it sets the position as evictable (moving its Shadow into the evictable set). If an evictable position is requested again, the Shadow can simply be moved into the reserved set and the component told to proceed.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Oct 04, 2022 at 11:14 AM PDT.

[EvanKirshenbaum]

One interesting wrinkle is how to deal with Pipettor shadows. The simplest notion is to say that there are shadows for getting to each Well and ExtractionPoint, but it might be simpler to simply have single shadows for different regions of the board (e.g., "left side", "right side"). A trickier question is what to do for deliveries to or extractions from multiple targets. Do we compute a shadow on the fly? Do we require reserving everything that's needed first? Do we move to a neutral position in between? Do we allow moving from one reserved position directly to another, reserving a path between? (And does this lead to potential for deadlock?)

Migrated from internal repository. Originally created by @EvanKirshenbaum on Oct 04, 2022 at 11:21 AM PDT.