feat: allow hardcoding of features via arguments to build script

[Daxtorim]

Summary

This PR introduces several flags to the build script that allows users to bake ligatures directly into the font and thus enabling them permanently. This is useful for those who want to use certain style sets or character variations in editors that otherwise don't allow for such features.

How can it be used?

Features to be baked in can be given to build.sh as a comma separated list with the -f / --features flag.
All features that were not already in their own files were pulled out of FiraCode.glyphs into individual files. There is no way I will write a parser for the glyphs file to do that at runtime. The build script will then read the code in these feature files and appends it to the calt property inside the glyphs file.

To more easily generate multiple font versions with different features baked in, there are flags -n / --family-name for build.sh that will allow users to set a custom family name for the font. The special value "features" will append the feature list to the font name. The family name is exported and used by the other build scripts as a directory to separate different font versions. The filenames were not changed, the directory name is enough separation.

Via another flag, -w / --weights, a comma separated list of font weights to be generated can be given to build.sh. This was already possible by specifying font weights as separate arguments to build_ttf.sh but now they can be given to the overall automated build script as well.

The flag -g / --generate-glyphs-only will cause the script to exit after the custom glyphs file has been created without actually building the font. I personally use this to generate a glyphs file I can then use with EzequielRamis/liga to patch other fonts with FiraCode's ligatures.

---

Note for the future

This implementation relies on the code for all features being inside a file called ./features/{name}.fea where {name} is the feature name, i.e. the code for the ss06 feature must be inside a file called features/ss06.fea. If that code contains lookups, those brackets must be on separate lines. Furthermore, the file must not contain inline comments (I don't know if these would be allowed in the first place). This is because all collected code blocks will be put on a single line.

This is ok:

lookup backslash_thin {
  ignore sub backslash.ss06 backslash';
  sub backslash' by backslash.ss06;
} backslash_thin;

# This is fine as well
lookup backslash_thin {
  ignore sub backslash.ss06 backslash'; sub backslash' by backslash.ss06;
} backslash_thin;

1. These are all NOT ok:

# 1. This entire line will be ignored by grep
lookup backslash_thin { ignore sub backslash.ss06 backslash';  sub backslash' by backslash.ss06; } backslash_thin;

# 2. The first line will be ignored, the second line will be collected though, which breaks the resulting glyphs file with an unpaired }
lookup backslash_thin { ignore sub backslash.ss06 backslash';  
sub backslash' by backslash.ss06; } backslash_thin;

# 3. This would end up commenting out all code below the inline comment
lookup backslash_thin {
  ignore sub backslash.ss06 backslash'; # Inline comment here,
  sub backslash' by backslash.ss06;
} backslash_thin;

# 4. Semicolon on the wrong line will cause the line to be collected, see second bad example
lookup backslash_thin {
  ignore sub backslash.ss06 backslash';
  sub backslash' by backslash.ss06
#v 
 ;} backslash_thin;

---

Closes #1383
Closes #1348

Related, close at your own discretion:

Issue	Reason
#1033	Requested different style binaries
#994	Requested different style binaries
#896	Editor without support for style sets
#869	pyftfeatfreeze does not work (see also here)
#842	Editor without support for style sets Requested different style binaries

[tonsky]

Thanks! This is a huge work, very impressive. An well-presented, too. I’ve merged it as 31adb24