Cleaner workflow for Monotype feature files

For the Noto project, our main vendor (Monotype, MTI) delivers feature files in the [Monotype feature file format](http://monotype.github.io/OpenType_Table_Source/otl_source.html); see [Noto Sans Khmer](https://github.com/googlei18n/noto-source/tree/master/src/NotoSansKhmer) for an example. fonttools.mtiLib can compile these files, but the fontmake workflow is messy because this side input gets injected late in the pipeline.

To clean this up, I wonder if we could change fontmake so it produces self-contained UFOs for the interpolation masters. Other than today, those UFOs would contain everything needed for being compiled to binary OpenType files. Instead of the usual “features.fea” in Adobe format, these UFOs would contain MTI feature files such as “features_GPOS.mti” and “features_GSUB.mti”.

Compared to what fontmake does today, this would be only a very minor difference: the same files in the same format as today, they just would get copied into the master UFOs early in the compilation process. Self-contained masters would make it easier for other tools (such as TruFont, or ad-hoc scripts) to process the Noto masters. Likewise for other fonts that get produced with a similar workflow.

Generating static UFO instances in this format would also be doable, but trickier (needs a decompiler). Personally, I care mostly about variable fonts, so I wouldn’t mind if this was only implemented for interpolation masters.