Make absolute-temperature handling in `Quantity` independent of hard-coded unit names

[seanpearsonuk]

In Quantity, there is pre-existing logic that detects absolute temperature values below physical limits and converts the unit to a delta unit:

if (
    (units.name in ["K", "R"] and min_val_float < 0)
    or (units.name == "C" and min_val_float < -273.15)
    or (units.name == "F" and min_val_float < -459.67)
):
    units = Unit(f"delta_{units.name}")

This approach relies on hard-coded unit names and numeric thresholds. While it works for the currently supported units, it is fragile and difficult to extend or reason about.

Issues with the current approach

• Logic is tightly coupled to specific unit names ("K", "C", "F", "R").
• Physical semantics (absolute vs delta temperature) are inferred indirectly.
• Adding new temperature units or aliases would require updating this conditional logic.
• The intent of the code is not immediately obvious.

Suggested direction (non-prescriptive)
Consider expressing this logic in terms of unit metadata or physical dimensionality rather than string comparisons, e.g.:

• Explicit absolute-vs-delta temperature classification
• Unit properties describing valid absolute ranges
• Delegating physical constraints to the units system rather than Quantity

This issue is low priority and not intended to block any current work; it’s about improving robustness and long-term maintainability.

@hpohekar

Just an observation on pre-existing code (low priority, I’ll raise a follow-up issue).
This logic depends on hard-coded unit names, which makes it fragile and hard to extend.
We’ll likely want a more robust way to express this in future.

Originally posted by @seanpearsonuk in #483