Use other tables generated by fea-rs

[cmyr]

feature files can end up creating or modifying a bunch of different tables; see https://github.com/cmyr/fea-rs/blob/main/fea-rs/src/compile/output.rs#L22 for the list. It is likely that many of these are rarely used, but at the very least we should be checking if they're present.

[rsheeter]

I'm inclined to say we should start by erroring if fea gave us back any table we don't deal with

[rsheeter]

We'll want to check which things fontmake accepts to be defined by fea and how it handles multiple definitions

[anthrotype]

Fontmake accepts anything that fonttools feaLib returns with no questions, those are not multiple definitions but rather "overrides"

[anthrotype]

That's how Adobe FEA spec describes these, and also how makeotf interprets them

[rsheeter]

Is there any case where you have to merge the results or can you always take teh whole table from fea? - for example, I think Colin said you can set modified time in fea and that made me think you'd need to take just that field and copy it into the table you built from non-fea sources. If we can just always take the whole table that would be nice.

[anthrotype]

You'd take the whole thing, the feature compiler is responsible for applying the overrides

[rsheeter]

If the fea compiler is to apply overrides it would have to have access to the thing it is to apply them to? And that makes for all sorts of execution order limitations, e.g. if fea can override modified in head then we must run fea after we make head and we have to somehow make our head available to fea-rs`?

[cmyr]

I think that having the fea compiler be responsible for merging is a bit of a layering violation; you should be able to compile FEA without knowing much about the final font. I would propose a design where fontc inspects the tables returned by fea-rs and merges them as required.