refactor(api): Relocate module location validation to engine

[CaseyBatten]

Overview

See: RQA-2577
Prevents the engine from accepting load module commands in locations for modules that match the deck configuraiton but would not have passes protocol core validation.

Test Plan

If a maintenance run is created with a load module command loading a thermocycler in slot A1, expect that an error will be raised by the robot containing the line:
ValueError: A thermocyclerModuleType cannot be loaded into slot A1

Changelog

Previously we ensured that a module location was valid on the protocol core. This was acceptable previously as module locations were whitelisted based on their definitions. Now our dependency hierarchy has changed however. When a module is configured, it must first be added to the deck config. In order to add it to the deck config, it's fixture must allow it to load into a given mayMountTo location. This results in the same behavior as our definition dependency before, however in the case of the thermocycler both A1 and B1 became valid load slots because its fixtureGroup spanned both slots. This meant the engine could now validate a load_module engine command with a thermocycler in A1 so long as the deck provided a valid related fixture. PAPI protocols would prevent this because protocol core had stricter validation requirements. In order to correct this, the _ensure_module_location(...) validation has been relocated to the engine load_module logic so that all validation occurs engine-side, preventing historically unsupported load locations.

Risk assessment

Low, the same validations are occurring we are just more thorough that before.

[b-cooper]

looks good to me 👍