Use the OS/2 width class to map the wdth axis

[belluzj]

Possible improvement on the situation in googlefonts/fontmake#470

@anthrotype

[anthrotype]

This change shold have been discussed a bit more, or at least better documented. I only realized the effect of this now.
Basically all the noto-source variable fonts that have wdth axis have their fvar table modified by this (plus they get an additional avar SegmentMap for wdth axis, where previously avar only contained maps for wght).
Previously the wdth axis minimum in fvar was 70 (default 100 and maximum 100); now the minimum is 62.5, which is the percentage associated to "Extra Condensed" OS/2.usWidthClass (2).

I'm still not sure if I should change (and how?) the noto-source files to have them produce the same fvar/avar tables as before, or if the change is innocuous and for the good.

[anthrotype]

but i looks to me like a breaking change, since anybody who was relying on the old behavior, namely that glyphsLib would not generate axis maps for wdth axis (i.e. assuming that master/instance locations for wdth axis were already in the same coordinate-space as in the fvar user-space coordinates), would now get possibly unwanted changes in the generated fvar (and avar) when building their font with glyphsLib >= 3.3.0.

[belluzj]

I implemented this from your comments in googlefonts/fontmake#470 (comment)

I think that your original comment still makes sense, and that the design locations and user locations should be able to be chosen independently.

[anthrotype]

the design locations and user locations should be able to be chosen independently

yes, but in a way that doesn't break existing fonts

[anthrotype]

reverted with 746ad75

let's continue discussing on this in #483