Precision of conversion between non-primitive units

Our work on unit conversion in Amount has thus far focused on single unit conversions, such as converting between units like foot and meter. For these, the total count of units is sufficiently limited that we ought to be able to precalculate the values necessary to ensure that conversions are as accurate as possible when done in the Number space.

However, we also intend to cover unit categories like "speed", where it's reasonable to expect that a user might want to convert e.g. a speed measured in meter-per-second to mile-per-hour. The conversion here is x / (0.3048 * 5280) * 3600, and even if an implementation were to precalculate and store the meters-to-miles multiplier (1 / (0.3048 * 5280)), we'd still end up with two sequential multiplications, with an intermediate result potentially enforced to be a Number.

While we could precalculate all of 1 / (0.3048 * 5280) * 3600, that doesn't scale well to covering all possible combinations, which would include all sorts of unlikely but not impossible conversion pairs like going from watt-per-joule to horsepower-per-calorie.

I suggest that it would be reasonable for us not to promise the same kind of accuracy with -per- units that we can promise for single-unit conversions. As this does run the risk of allowing for imprecise outputs, we should consider limiting the roundingMode values that we offer to minimize the impact of these imprecisions.

Start by reviewing the Amount conversion design for compound “-per-” units and the proposed roundingMode values; the issue names no implementation files or tests. Done requires a decided policy for precision and supported rounding modes for non-primitive unit conversions.