feat(shared-data): add liquid class definition for water

[sanni-t]

WIP

Addresses AUTH-833

Overview

Adds definition for water.

I have added placeholder values for all OT2 and Flex pipettes with their respective compatible, regular Opentrons tipracks (non-filter). @andySigler will be adding the actual values.

Test Plan and Hands on Testing

• TODO: add a test to verify schema compatibility of the definition

Review requests

• see questions in comments

Risk assessment

None

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.36%. Comparing base (094be6e) to head (de8d777).
Report is 21 commits behind head on edge.

Additional details and impacted files

@@             Coverage Diff             @@
##             edge   #16671       +/-   ##
===========================================
- Coverage   92.43%   79.36%   -13.08%     
===========================================
  Files          77      120       +43     
  Lines        1283     4493     +3210     
===========================================
+ Hits         1186     3566     +2380     
- Misses         97      927      +830     

Flag	Coverage Δ
g-code-testing	92.43% <ø> (ø)
shared-data	74.14% <100.00%> (?)

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

Files with missing lines	Coverage Δ
...n/opentrons_shared_data/liquid_classes/__init__.py	80.00% <100.00%> (ø)

... and 42 files with indirect coverage changes

[sanni-t]

pipetteModel is not appropriate for the value we are using here- which is the API load name of a pipette.
We should do one of these things-

1. Call this field pipetteLoadName so that it is more appropriate. Keeping the pipette identity be pipette load name makes it straightforward for if & when we allow custom liquid class definition files. Users know the pipettes by their API load names and hence will find it intuitive to use the load name. But, this will make it a bit convoluted for PD because PD uses engine-relevant pipette naming.
2. Keep pipetteModel and use true model names, i.e., p10, p20, p300, etc. This will only work (and in fact would be preferred) if the liquid class values are identical for all generations of the given pipette model
3. Change to pipetteName which will be the name used in all layers except the PAPI layer. This name is the same as API load name for the OT2 pipettes. It diverges from the API load names of Flex pipettes.
   Pros: More straightforward when using PD, and consistent with the name that most of our backend uses
   Cons: Will be confusing if/when we allow users to create their own custom definitions files. But maybe that won't be a problem if the primary way a user will create custom liquid class definitions is by using some Opentrons software (custom liquid definitions creator?). Also this won't pose much of a problem when defining custom liquid classes in the API because we can always do the PAPI-load-name <-> PE-load-name conversion.