This makes the output of feaLib more compact, using a similar technique
as seems to be used by makeotf.
After this change, feaLib generates output that more similar to makeotf:
* For the test cases in `bug512.fea` and `bug463.fea`, feaLib now
generates the exact same output as makeotf v2.0.90.
* For the test cases in `GSUB_6.fea`, it is hard to say because makeotf
crashes on the test file; our test contains language constructs that
are valid according to the spec, but didn't yet get implemented by makeotf.
When commenting out those constructs, feaLib generates the exact same
output as makeotf v2.0.90.
* For the test cases in `feature_aalt.fea`, the output of feaLib is now
structually the same as the output of makeotf v2.0.90. However, two
lookups are in different order. feaLib's ordering reflects the order
of statements in the compiled input source; no idea why makeotf would
want to reverse the ordering. Since this ordering difference only
affects the _targets_ of chain substitutions, there is no semantic
difference.
Resolves https://github.com/behdad/fonttools/issues/512.
For this construct, makeotf throws an error: "Contextual alternate
rule not yet supported". If it had been implemented, we speculate
that the ordering would likely be the same as with other contextual
substitutions (the chain comes before, not after, the dependent lookup).
https://github.com/behdad/fonttools/issues/507
Before this change, feaLib had assigned a lookup index at the same
time as compiling each lookup. For chains, the implicit assumption was
that the chain's targets would always come before the contexual chain.
Normally this was indeed the case, but feaLib (and also makeotf)
sometimes merge several chain targets into one single lookup,
and then this assumption was not true anymore.
In the new version, the lookups get compiled in a separate pass,
after assigning lookup indices.
https://github.com/behdad/fonttools/issues/463
https://github.com/behdad/fonttools/issues/445
Not sure whether it makes much sense to define a contextual chain
that points to a GSUB type 3, but the OpenType feature file syntax
does not explicitly forbid it. Adobe's `makeotf` tool rejects this
kind of input with "Contextual alternate rule not yet supported";
this implies that the construct is valid (albeit definitely exotic).
Before this change, the compiler had (essentially) implemented lookup
references by inlining the statements of the invoked lookup into the
current feature block. After this change, the lookup gets compiled
separately, and any call sites make explicit calls.
