Change implementation of desiccated font files #104
Description
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 but 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.