LCOX calculation with strict enforcement of units

[tsmbland]

Description

Please include a summary of the change and which issue is fixed (if any). Please also
include relevant motivation and context. List any dependencies that are required for
this change.

Type of change

• Bug fix (non-breaking change to fix an issue)
• New feature (non-breaking change to add functionality)
• Refactoring (non-breaking, non-functional change to improve maintainability)
• Optimization (non-breaking change to speed up the code)
• Breaking change (whatever its nature)
• Documentation (improve or add documentation)

Key checklist

• All tests pass: $ cargo test
• The documentation builds and looks OK: $ cargo doc

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 96 lines in your changes missing coverage. Please review.

Project coverage is 84.63%. Comparing base (4473c5d) to head (4220983).
Report is 29 commits behind head on main.

Files with missing lines	Patch %	Lines
src/metrics.rs	0.00%	48 Missing ⚠️
src/units.rs	0.00%	48 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #481      +/-   ##
==========================================
- Coverage   87.04%   84.63%   -2.41%     
==========================================
  Files          38       40       +2     
  Lines        3372     3468      +96     
  Branches     3372     3468      +96     
==========================================
  Hits         2935     2935              
- Misses        250      346      +96     
  Partials      187      187              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[alexdewar]

It seems like this approach could work and there would be definite advantages to doing things this way. My main concern is that we might end up wanting more arithmetic operations, but then again, they probably wouldn't be that hard to add and realistically we're not doing much in the way of fancy maths anyway, so even a fairly basic set of operations would probably do us fine.

I think you could simplify the use of the macros a bit.

1. unit_struct!(A) could also define multiplication ops for Dimensionless (both A * Dimensionless and Dimensionless * A) and division ops
2. You could define a separate macro for creating units that are two other kinds of units divided together, e.g. unit_div_struct!(A, B, APerB), which would also define operations like A / B = APerB and B * APerB = A etc.

That should make it more readable and easier to add new units (if we ever need to).

You could also define From<f64> for Dimensionless and vice versa as converting between these types is harmless (in contrast to other unit types).