refactor(api): Port AddressableAreaStore to StateUpdate

[SyntaxColoring]

Overview

Closes EXEC-755.

Test Plan and Hands on Testing

• Make sure all automated tests (in particular, the analysis snapshot tests) keep passing.
• Run some random protocols on a Flex and OT-2 and make sure there aren't any unexpected errors related to addressable areas or deck configurations.

Changelog

Following the usual pattern of EXEC-639, port:

• AddressableAreaStore
• LoadLabwareImplementation
• MoveToAddressableAreaImplementation
• MoveToAddressableAreaForDropTipImplementation
• LoadModuleImplementation

So that the command implementations use StateUpdate to tell AddressableAreaStore what addressable area they have used, instead of AddressableAreaStore trying to figure it out for itself.

Review requests

See the risk assessment below and the comments on the diff.

Risk assessment

Medium.

This needs careful code review to make sure that the end result on AddressableAreaState is unchanged; the code removed from AddressableAreaStore should be exactly compensated by the code added to the command implementations.

These command implementations did not have full unit test coverage of all the stuff they did with addressable areas and deck configurations, and even if they did, it's very possible for me to mess things up. I initially had one bug where I had LoadModuleImplementation load a completely wrong addressable area, and it was only caught by an analysis snapshot test that I guess happened to have a specific deck layout.

LoadLabwareImplementation and its tests in particular have grown to be difficult to verify.

[jbleon95]

This all looks accurate to me, I answered the questions I could. Thanks for updating this.

[CaseyBatten]

This all looks good, thanks for the migration. Test coverage looks good, particularly on the module addressable areas. Commented on the hanging question regarding module load location.

[SyntaxColoring]

Thank you both!