Split borderline °F temperature assertion into sub-expressions

[DarkAndHungryGod]

The 1°F assertion in testTemperature() (DefinitionTests.swift) packs a lot into a single expression: a throwing optional unwrap, a mixed Int/Double literal chain (273.15 - (32 * 5.0 / 9.0)), two .measured(in:) calls, a throwing +, and a .convert(to:). That sits right at the Swift type-checker's per-expression time budget.

It compiles today, but with no margin. On a slower toolchain it tips over into:

DefinitionTests.swift:266:9: error: the compiler is unable to type-check
this expression in reasonable time; try breaking up the expression into
distinct sub-expressions

I hit exactly this on the macOS CI runner while working on a separate change (converting Quantity from an enum to a RawRepresentable struct, which slightly raises the constraint-solver cost of every measurement expression — enough to push this one over the edge on the slower macOS compiler, while all the Linux jobs stayed green). The expression is fragile regardless of that change, so it's worth hardening on its own.

This takes the compiler's own advice and splits it into typed sub-expressions — identical arithmetic and assertion:

let fahrenheitOffset: Double = 273.15 - (32 * 5.0 / 9.0)
let fahrenheitScale: Double = 5.0 / 9.0
let oneFahrenheit = try fahrenheitOffset.measured(in: .kelvin) + fahrenheitScale.measured(in: .kelvin)
try XCTAssertEqual(
    XCTUnwrap(Measurement("1°F")),
    oneFahrenheit.convert(to: .fahrenheit),
    accuracy: 0.0001
)

testTemperature passes locally and the expression now type-checks well within budget.

[NeedleInAJayStack]

Hey, thanks for submitting this fix! I hadn't considered the compiler complexity when I wrote this. I think it would actually make more sense to just switch to the literal double that represents 1F in Kelvin within our acceptable margin of error instead of computing it algorithmically. Could you make that change?

[DarkAndHungryGod]

Good call — done. Replaced the algorithmic computation with the literal kelvin value for 1°F (255.927778, i.e. (1 - 32) * 5 / 9 + 273.15), which converts back to 1°F to within ~4e-7 °F, well inside the test's 0.0001 tolerance. The mixed Int/Double arithmetic is gone, so the type-checker complexity is removed entirely. Force-pushed to the branch.

[NeedleInAJayStack]

Looks awesome! Thanks!