`:unit` needs to support data slicing

[sffc]

Currently, :unit suffers from many of the same problems as, for example, u:locale, explained in #1006.

Since the unit being formatted is provided by the Measure input type (which I think is a good decision), the message formatter cannot know ahead of time which units are being formatted, so it needs to pessimistically link the data for all possible units. Unit display names are among the largest chunks of data, so requiring this behavior is a non-starter for ICU4X.

A few ways to mitigate this:

1. Add the quantity to the unit function, such as :unit:length, as suggested by @eemeli. This would allow ICU4X to link only a smaller subset of units, which should be generally small enough to be manageable.
2. Require the quantity or the unit to be specified in the message. For example, :unit unit=meter with a Number input is OK, as is :unit quantity=length with a Measure unit.
3. Require a unit to be specified in the message, but allow the unit to be overridden by Measure so long as the quantity matches. For example, :unit unit=meter can be formatted with a Measure carrying foot but not a Measure carrying gallon.
4. Require the context to be specified in the message, and tweak how context works. :unit context=length would not do conversion, but conversion would happen with :unit context=length-road.

CC @macchiati @Manishearth

[sffc]

Responding to the following comment from @macchiati

What might work is for unit is to only require a small subset of unit ids to be supported. Then ICU4X and other memory-limited implementations could choose to only support the required set.

I don't think this is a good long-term solution. In ECMA-402, we struggled to come up with a subset list of units, and we landed on about 40, but users keep coming to us asking for more units. I would like to not repeat this in MF2.

[macchiati]

I'm a bit puzzled, because each of your solutions requires the message to be parsed by something, in order to find out the quantity. But if the parser sees :unit unit=meter, then knows (with a small table of information) that the quantity is length. So you can load the units with quantity=length.

[More precisely, in the general case it needs to load the units that are convertible to meter, which also includes inverse quantities. This happens, for example, with mph and liters-per-100-kilometers.]

Why would we need to force message writers to supply that information?

[sffc]

:unit unit=meter is fine. Where it breaks is if the unit is specified by a Measure input (which is a good choice, but it makes data slicing harder).

[macchiati]

:unit unit=inputUnit would also be at issue. Perhaps something like an optional convertible=meter,… would allow the message writer to supply the information you need. I could certainly see something like that in the localization chain as a requirement on localization venders for messages for a given project, say, a watch UI.