Allow override default values of vmtx in FEA syntax

[NightFurySL2001]

Quote from current FEA syntax spec regarding vmtx table:

In OpenType, each glyph may have a unique vertical origin y coordinate and a unique vertical advance width. By default, for each glyph the vertical origin y coordinate is set to the value of the OS/2.TypoAscender field, and the vertical advance width is set to the distance between the values of the of OS/2.TypoAscender and the OS/2.TypoDescender. However, other values may be assigned to a glyph as follows:

table vmtx {
    VertOriginY <glyph> <number1>;
    VertAdvanceY <glyph> <number2>;
} vmtx;

It was safe to assume that OS/2.sTypoAscender and OS/2.sTypoDescender are align to the ideographic em-box per current CJK industry standard. However, Google Fonts has recently changed the vertical metric requirements for CJK fonts with a new standard that was not observed in CJK fonts before, which includes spacing out OS/2.sTypo* values to include extraneous line gaps by default, and also using the BASE table to store the ideograhic em-box values.

The discussion can be found on google/fonts#8911 and googlefonts/googlefonts.github.io#159.

The current AFDKO toolset does not allow changing the default values for the vmtx table. A new syntax is required to define the default vmtx values.

Suggestions for vmtx syntax extension

Suggestion 1: without glyph name. This should only appear once in the table block.

 table vmtx {
     VertOriginY <number1>;
     VertAdvanceY <number2>;
 } vmtx;

Suggestion 2: add two new keywords: defaultVertOriginY/defaultVertAdvanceY as in the VORG. New keywords are required.

 table vmtx {
     defaultVertOriginY <number1>;
     defaultVertAdvanceY <number2>;
 } vmtx;

Suggestion 3: use the DFLT/dflt/includeDFLT keyword. Might crash with glyph names?

 table vmtx {
     VertOriginY includeDFLT <number1>;
     VertAdvanceY includeDFLT <number2>;
 } vmtx;

Suggestion 4: use the DFLT/dflt/includeDFLT keyword with a bracket.

 table vmtx {
     VertOriginY [dflt] <number1>;
     VertAdvanceY [dflt] <number2>;
 } vmtx;

Suggestion 5: instead of defining new entries, read the metrics from BASE table vert.ideo and vert.idtp. However BASE does not provide VertAdvanceY directly, instead only provides the ascender/descender values similar to how current OS/2.sTypo*. Note that many font editors does not support BASE table yet.

Fallback to OS/2.sTypo* should still be kept to maintain backwards compatibility.

CC @aaronbell.