Build system for CJK fonts

Currently Google Fonts seem to slowly start to accept CJK fonts after a long period without CJK fonts except Noto CJK. That is a good thing, except when it comes to the build system everything went haywire.

In the current documentation, Google Fonts allowed any build system as long as it uses only open-source tools and is repeatable with one command (or at lease one `build.sh` file).

https://github.com/googlefonts/googlefonts.github.io/blob/27a81526ff40693e533cb25be39fb0284c7d0dc0/gf-guide/production.md?plain=1#L50C1-L50C136
> - **Fonts should be built using open-source tools**.** This ensures that they can be built under the same conditions on any platform.
>
> - **Fonts should be built in one step.** All GF font production tools can be run from the command line. This allows to use them to generate font families by running a single command.
> If the build process necessitates more than one step / one command, then every step needed to build the fonts should be included in a single build script. See [the chapter about building fonts](build.md) for more information.
>
> - **Font builds must be repeatable.** Given all of GF tools are written in Python and distributed using [pypi/pip](https://pypi.org/), this allows to use specific versions of each package, ensuring the same conditions for each build with the same quality of results.

And a list of build tools are provided in https://googlefonts.github.io/gf-guide/build.html:

> [Fontmake](https://googlefonts.github.io/gf-guide/build.html#fontmake)
> [gftools](https://googlefonts.github.io/gf-guide/build.html#gftools)
> [gen-stat](https://googlefonts.github.io/gf-guide/build.html#gen-stat)
> [gftools builder](https://googlefonts.github.io/gf-guide/build.html#gftools-builder)
> [Useful tools](https://googlefonts.github.io/gf-guide/build.html#useful-tools)

However, after observing (and working with a few) the onboarding process, it seems that the GF team currently only accepts the makefile build system for CJK fonts and reject any currently-using build system. This has caused delays and frustrations among font designers, where many of them do not have any knowledge of programming or software development.

For example, the currently live [LXGW Wenkai TC](http://github.com/lxgw/LxgwWenkaiTC) had undergone an overhaul of its original build system by @\aaronbell (observe tagged [v1.330](https://github.com/lxgw/LxgwWenkaiTC/tree/v1.330) before the overhaul and [v1.500](https://github.com/lxgw/LxgwWenkaiTC/tree/v1.500) after the overhaul). I had personally worked with the font designer LXGW in https://github.com/lxgw/LxgwWenkaiTC/pull/16 , where the designer had many questions on why the Latin parts were separated and the original source files are abandoned. Although the final build system is better in terms of modularity, it had made the font designer's job harder as his original source files cannot be used anymore, and instead be forced to use the new UFO files generated by @\aaronbell in the build system, which is originally made with Glyphs where both the font designer and me don't have. I had to research on how to convert the UFO files back to workable source files for the font designer, and helped him to migrate the other Wenkai repo to use the same build system locally.

The same actually happened in https://github.com/lxgw/LxgwMarkerGothic/pull/7, where this time it is not even obvious why the build system has to be changed when the original `fontmake` build system works perfectly. The original repo uses `fontmake` because that was what GF was suggesting at the time of release, and `gftools` weren't stable to work with.

Another is the currently live [Cactus Serif](https://github.com/MoonlitOwen/CactusSerif), where the build system is replaced from a `build.sh` file to makefile in https://github.com/MoonlitOwen/CactusSerif/pull/2 . This is quite unnecessary and the reason given is only "Updated the build system to use GF's standard builder tool.", which they were already using (in `build.sh` it was calling `gftools builder`). The source files are also regenrated with Glyphs, which as usual, the original font designer doesn't have. I do not know the font author personally so I couldn't provide help for him, and the build system change ended up not merging into the upstream which breaks the version control flow in the future (e.g. https://github.com/google/fonts/issues/8694 this bug was introduced in downstream by @\aaronbell, so downstream has to bump one version without upstream bumping the version).

There are also reasons to not use the `gftools builder`, like when I was trying it out and could not choose the overlapping backend as `gftools builder` did not provide the correct option. This is reported in https://github.com/googlefonts/gftools/issues/654 and only fixed after 1 year, where I had to let https://github.com/maoken-fonts/unbounded-sans stay with `fontmake` because `gftools builder` couldn't do what I need it to do. Other build systems that aren't using the `fontmake`/`gftools` buildchain exist too, like Adobe's Source Han / Google Noto which uses the AFDKO system.

These issues have raised a concern that if the GF team had any compulsary requirements that all new onboarding font must use the new makefile build system, which takes a long time from @\aaronbell and break the font designer's workflow altogether. I hope the GF team can provide some accurate answer/stance on this issue.