Change implementation of desiccated font files

[skef]

The current approach to EncodingConfig, and therefore the encoder, signals a desiccated font file by way of an encoding with no "base" entries. While this makes some sense in terms of simplicity I think it would be better to separate the two concepts.

One minor aspect of this is that a desiccated file should lack much more than shaping information; it doesn't need a name table or an hmtx table or even rump glyf or CFF tables. However, absent other considerations it would be fine to hinge whether to desiccate on the lack of base entries. One could always throw .notdef in to make the difference.

The more compelling reason to separate the two is because the idea of base entries is still useful even when you intend to desiccate. Among other things the base is where you might throw entries that pose analysis issues and having to juggle them into each of the initial table-keyed patches, and then juggle them back out for subsequent patches, would be a pain. (It breaks the OutgoingEdges model, for example.)

In addition, we've extended the specification to allow multiple patches to be applied in order when a single patch map entry is selected. So we now have a cleaner mechanism for desiccation: Make a single patch that, when applied to the desiccated file produces a "full" initial file (with rump glyf/CFF) and then add the locale- (or whatever) specific patches on top of that. This makes it quite straightforward to separate the two ideas at the encoding level.

[garretrieger]

Makes sense to me. How's this sound:

• Add an additional boolean to the config that says whether to dessicate the initial font. True dessication (removing nearly all tables other than IFT/IFTX) still needs to be implemented.
• If desiccating, then initial subset config (if present) forms a couple patches (glyph keyed + table keyed) which are always loaded (mapping entry is *) and pull in needed data for initial subset config.
• Incorporate Change Encoder::OutgoingEdges mechanism to use the multi-patch feature #103 as suggested into all this.

[skef]

Yes, that sounds about right.