Implement direct conversion functions

[tmilnthorp]

Implementing direct conversion functions would help reduce error. Currently, to go from ounces to pounds, we go:
ounces -> kilograms -> pounds

This shows an example of going directly from ounces -> pounds.

Long term, we could move all FromUnitToBaseFunc/FromBaseToUnitFunc into this conversions array.

Just a quick example to show what's on my mind.

[angularsen]

I like it 💖
It seems like a natural next step for the conversion functions you added in #588.

[angularsen]

DirectConversions maybe, to be more explicit that this is an optional thing?

[tmilnthorp]

@angularsen I think I would actually make it mandatory. I may take in stages, but maybe the first stage is the convert the current FromUnitToBaseFunc/FromBaseToUnitFunc to the Conversions?

[angularsen]

Oh gotcha, yes I suppose we could refactor the existing definitions to this.

The upside is more explicit naming, the old naming is kinda confusing. Also gathering all conversion functions, both direct and via base, in one place might be better.

The downside is that it is maybe not as obvious that the conversions need to go via a "base" unit, but we could maybe fail codegen if any unit has missing conversions from/to base unit?

[angularsen]

I think we should close this PR now as superseded by #1544.

The motivating issue was precision loss from converting through an intermediate base unit, for example ounces -> kilograms -> pounds. Current master now uses fraction-backed QuantityValue and exact generated ConversionExpression metadata, so this specific example is already exact while the value stays as QuantityValue: 1 oz -> 1/16 lb and 1 lb -> 16 oz.

Generated quantities no longer own a TryToUnit switch; .As() and .ToUnit() now go through UnitConverter and UnitInfo conversion expressions. If we later find a remaining use case for direct same-quantity overrides, I think that should be designed in the UnitInfo/UnitConverter metadata layer with validation and clear precedence rules.