feat(api): add new user-facing helper functions for static liquid tracking

[caila-marashaj]

Overview

This provides the protocol api with some new lld-related functions for users:

1. InstrumentContext.get_minimum_liquid_sense_height() -> float
   provides the minimum allowed liquid-level detection height for a given pipette and tip combination

2. Well.estimate_liquid_height_after_pipetting(starting_liquid_height: float, operation_volume: float) -> float
   provides the projected ending height of the liquid meniscus after an aspirate or dispense. Note that it will have to be provided with a starting_liquid_height in the protocol, but this can be grabbed from InstrumentContext.measure_liquid_height. This will not propagate an InvalidLiquidHeightFoundError if the result it finds is an invalid well location.

3. Well.current_liquid_height(self) -> float: provides the current known liquid height. If no liquid is probed or loaded in before this is called, it will cause a LiquidHeightUnknownError.

4. Well.current_liquid_volume(self) -> float: provides the current known liquid volume. If no liquid is probed or loaded in before this is called, it will cause a LiquidVolumeUnknownError.

Changelog

• Change the name of get_well_height_after_volume to get_well_height_after_liquid_handling
• To enable calculating what the liquid height will be before calling aspirate or dispense, add a new get_well_height_after_liquid_handling_no_error in geometry.py
• 4 new api functions above and their wiring to the protocol engine
• add a LiquidVolumeUnknownError for when we try to call well.current_liquid_volume but no liquid has been loaded or probed
• add an option in find_height_at_well_volume to disbale throwing an InvalidLiquidHeightError, to enable estimating liquid height without making an aspirate or dispense move
• add a get_well_current_volume in geometry.py to get the volume from the most recent well liquid info

Review Requests

• get_well_height_after_liquid_handling_no_error could just be implemented as the addition of a raise_error_if_result_invalid argument to get_well_height_after_liquid_handling, but I made it a separate function so it would be harder to disable raising that error by accident and causing a collision. Thoughts on this?

[sfoster1]

The idea behind the changes looks good, but I think by changing where and how some of these methods are called we can reduce complexity some. I like the engine internal refactor.

Please add tests for all of this.

[sfoster1]

I think we can pull one more argument from estimate_liquid_height_after_pipetting and keep it to just operation_volume.

[sfoster1]

Looks good to me, but please update the description (and the resulting commit message when you merge) for the changes that you've made