feat(api): add and use inStackerHopperLocation

[sfoster1]

Labware objects that are in the stacker hopper have the new location InStackerHopperLocation, which also identifies the labware Id of the stacker in question.

In this PR, we set the location of labware that get loaded onto the stacker module while static=False to InStackerHopperLocation. However, after the rest of the work in the epic, the only way to get a labware into InStackerHopperLocation is to pass it to stacker/store. It's not a location you can specify in any parameters, which is already true in this PR.

Because we're adding it fresh and thus it isn't already serialized anywhere, we can give the location object a kind member and therefore don't have to have a separate location sequence component.

review requests

does this look like the right data? are we happy with it?

testing

none required, this is well-covered by internal tests and the data that it exposes that changed isn't actually used by anything yet.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.62%. Comparing base (6ce82af) to head (cf49ac9).
Report is 3 commits behind head on edge.

Additional details and impacted files

@@           Coverage Diff           @@
##             edge   #17535   +/-   ##
=======================================
  Coverage   63.62%   63.62%           
=======================================
  Files        2838     2838           
  Lines      218019   218019           
  Branches    18107    18107           
=======================================
  Hits       138704   138704           
  Misses      79122    79122           
  Partials      193      193           

Flag	Coverage Δ
protocol-designer	18.85% <ø> (ø)
step-generation	4.36% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
shared-data/command/types/setup.ts	100.00% <ø> (ø)

[caila-marashaj]

Looks good to me. The way it works is you'll store a labware in a hopper, creating one of these new location types with an eventualDestinationSequence, and then calling retrieve will update the locations of all the labware in the hopper?

[sfoster1]

Looks good to me. The way it works is you'll store a labware in a hopper, creating one of these new location types with an eventualDestinationSequence, and then calling retrieve will update the locations of all the labware in the hopper?

Actually no; the only way you can get this location is storeing a labware there. Rather than loading labware instances into a stacker, you'll configure its labware pool.

[CaseyBatten]

Looks good overall but I think your tests cases that utilize possibleCutoutFixtureIds are going to start failing if you merge edge in as they do not list all the possibilities? If thats not the case I'll come back and approve.

[CaseyBatten]

Will this need to be updated to include the following (and in all your other tests that list the potential cutout fixtures)?:
"flexStackerModuleV1WithWasteChuteRightAdapterCovered",
"flexStackerModuleV1WithWasteChuteRightAdapterNoCover",
"flexStackerModuleV1WithMagneticBlockV1"

[sfoster1]

oh because you merged that other PR? i'll merge edge into this and see if it starts failing

[sfoster1]

Looks like it was just the one test @CaseyBatten , fixed up

[CaseyBatten]

Stupendiferous