This adds infrastructure for merging name tables. A stylistic set feature params are newly merged as a result (the feature names are joined into one name).

The way this is currently designed:

1. During pre-merge, a name record visitor reads the name strings and stores them onto the respective objects
2. During post-merge, another name record visitor reads the strings, merges them, adds the merged string to the name table, sets the resulting nameID on the object and deletes the stored strings from objects
3. If enabled using --merge-names switch, the system names (ID < 256) are merged during name table merging.

Is this approach reasonable? The name record visitor seems to take quite time for some fonts. The whole pre- and post-merge could be made opt-in behind the new switch, however, the layout merging would need to have access to the options during mergeFeature to know not to create any feature params. Alternatively, the name strings could be stored somewhere else and not on the objects where they are referred from.

The usage is demonstrated on mergeFeatureParams, however currently implemented for ss features only, not the others.

(also the original NameRecordVisitor was fixed to mark all names indicated by FirstParamUILabelNameID and NumNamedParameters as seen, not just the first name ID)