Rework feature file kerning.

This partially addresses #1888.

There were a number of problems, the most pronounced of which was the breakage of fea_classesIntersect. I tested extensively after updating said function previously with typefaces that used native U. F. O. data structures for class kerning but forgot to test with some that used the feature file for that purpose. This was breaking the import of all class kerning values. There was an additional problem (which appeared only after solving the first) whereby the function would null-terminate one of the two input strings after a single character.

There remain several problems to be resolved. Presently, FontForge reads the native U. F. O. kerning data first and creates kerning classes there. It then reads the feature file. Because the feature file lookups have names, they get created for each uniquely named occurrence in the feature file rather than merged with the lookups created previously. As such, whenever FontForge emits a typeface in its current mixed format (which we have not changed this year) with class kerning and pair kerning, it destines itself to read into separate lookups or subtables on import. So we need to discuss whether to default entirely to the native U. F. O. data (which would cause the loss of lookup/subtable names and script designations) or to default entirely to the feature file data (which is messy).

There is an additional problem that causes the class kerning and pair kerning from a common script, even in native U. F. O. storage, to create divergent lookups on import if the common script is not the default script. The kerning pair importer determines a script from its constituent characters and then finds or makes a subtable that matches that script. The class kern importer just uses the default script. The kerning pair approach seems more sophisticated, but, before I adapt it to the kerning class, I want to be sure that it is in fact what we want.