MTI features plist as custom parameter, exported to UFO data/

fontmake has an `--mti-source` option to load Monotype feature files from a plist file containing a mapping of OpenType table tags (GSUB, GPOS, GDEF) to text files containing feature specifications in MTI feature file format.
http://monotype.github.io/OpenType_Table_Source/otl_source.html
When building the master UFOs from a glyphs source, if that command line option is provided, fontmake reads the plist and copies the content of the referenced text files inside each master UFO's `data` directory, prefixed with a private reverse-domain prefix that ufo2ft uses to load these data files and pass them on to fontTools.mtiLib for compilation.

I would like that we could store the filenames of these external MTI feature files inside the Glyphs source file itself, in the form of _masters_ custom parameters, and the glyphsLib could read these upon building the UFO masters and store them in the data folder, just like fontmake does.

This way, the fontmake command line to build from a glyphs source file with MTI features would not contain the extra option and its output determined only by the content of the single input glyphs file.

This is how this plist files currently look like:

```xml

NotoSansCham-Light

GDEF
Noto Sans Cham GDEF.txt
GPOS
Noto Sans Cham 26-100 GPOS.txt
GSUB
Noto Sans Cham GSUB.txt


NotoSansCham-Regular

GDEF
Noto Sans Cham GDEF.txt
GPOS
Noto Sans Cham 90-100 GPOS.txt
GSUB
Noto Sans Cham GSUB.txt


NotoSansCham-SemiBold

GDEF
Noto Sans Cham GDEF.txt
GPOS
Noto Sans Cham 151-100 GPOS.txt
GSUB
Noto Sans Cham GSUB.txt


NotoSansCham-Bold

GDEF
Noto Sans Cham GDEF.txt
GPOS
Noto Sans Cham 190-100 GPOS.txt
GSUB
Noto Sans Cham GSUB.txt

```

Start by tracing glyphsLib's conversion of master custom parameters into UFO masters and data directories, then compare the existing fontmake --mti-source behavior. Done means filenames stored in each Glyphs master's custom parameters are resolved and copied into the corresponding UFO data directory so fontmake no longer needs the extra option.

Written by the indexing model from the issue text.