'mule-fonts' hadling (Re: gtk mule-fonts note)

. Use when adding specs So the `mule-fonts' specifier tag is for use only while adding specifications to specifier, and it is never used to restrict match while instancing specifiers. The tag is never used in specifications adding function calls done by `custom'. The tag may be used in those calls done by `x-symbol'. So `custom' allows and `x-symbol' requires the tag to be already defined. Just the same other packages may wish to add specifications that are intended for use by mule and must never be disturbed by `custom'. Such an additions certainly must be done only when `(featurep 'mule)', but other checks, including devices of what types currently exist, look very hard to specify (and provide). In particular, in `x-symbol' there are no obvious checks like that before using `mule-fonts'. Then the tag must be defined not after initializing devices of particular type, but just after loading `custom'. This must be done once, with a single predicate function, not twice with different ones, as done currently for X and GTK in 21.4. Since the tag is not intended to restrict instancing, its predicate should return true unconditionally. . Use when instancing? Or instancing restriction is also intended? Then there must be a list of device types that "support mule", and device type maintainers must update the list entries appropriately, so that a single predicate may be written that just checks the list, which will be the `mule-fonts' specifier tag predicate. Perhaps the best is an additional field in generic device type data that must be filled by device type maintainer, and a built-in predicate that just returns it. C core has to be changed anyway: even if the list is maintained in elisp, there must be a comment in C code telling device type maintainers to update it.