Compound `-per-` units should be supported

We already now support formatting X-per-Y units in Intl.NumberFormat, provided that X and Y are supported base units. We should also support converting between such compound units, where both units are mutually convertible.

An easy (and common) case for this type of conversion would be e.g. going from meter-per-second to kilometer-per-hour; supporting a conversion like this seems rather uncontroversial. Two other cases that come to mind that may need some discussion:

1. Converting between mile-per-gallon and liter-per-100-kilometer, which inverts the terms. Specifically these two units are important, as they are the preferred consumption units for different regions.
2. Converting between EUR-per-kilometer and EUR-per-mile, i.e. compound units where one part is not a supported convertible unit, but is an exact string match between the source and the target. This was tangentially discussed also in #18.

Are there other corner cases that we should explicitly consider for -per- units? My initial sense is that we should support all of the above.

As discussed in #140, any conversions between compound units is likely going to need a sequence of Number operations, and therefore introduces inaccuracies from their multiple rounding steps.

The issue names no files or tests. Start by reviewing the existing X-per-Y formatting support, then read the related discussions in #140 and #18 and the linked CLDR preferred-unit data. Done means reaching an explicit decision on convertible, inverted, and exact-match terms before implementing and testing the agreed behavior.