pipline: binaries – should we build from source (in packager)?

This came up when I recently used the packager to start the PR/QA processes for updates of some SMC fonts namely , [Manjari](https://github.com/google/fonts/pull/2572), [Gayathri](https://github.com/google/fonts/pull/2573) and [Chilanka](https://github.com/google/fonts/pull/2574).

The main motivation was that SMC has no font binaries in their repos. However, they plan to attach font binaries to GitLab releases in the future, so this issue may not be terribly relevant. I'm posting this to collect thoughts and direction on how to go on.

There are two more issues that came up with this:

* accept GitLab/other git hosts googlefonts/gf-docs/#75
* use GitHub (GitLab) release attachment binaries #230

For the three PRs referenced above I modified the `gftools packager` to accept a `build` field in it's upstream config, e.g:

https://github.com/google/fonts/blob/581699fcc0df7715a0f944e28b1a18d38e4aad62/ofl/chilanka/upstream.yaml#L23-L30

```yaml
# optional commands to build, using bash -c {build}
# if you need a python virtual env, this must be created with build as well
# TODO: sandboxing and venv creation should be handled by the tool, maybe
# using docker ...
# FIXME: for FDB this is a security issue! should only run sanctioned/signed
# scripts. Maybe we can have a secure $ gftools fontmake ...
build: mkdir -p build; python3 -m venv build/venv; source build/venv/bin/activate;
pip install -r requirements.txt; make ttf
```

I think it's a nice workflow to have this in the packager. But:

* This has security implications, e.g. in this case the `Makefile` in the repository could execute code that is malicious, e.g. when a build dependency on pypi.org was compromised (things like this happen). So, at least for a Font Bakery Dashboard application, just running any script is not good enough. And also anyone who executes the packager locally with an upstream configuration that has a `build` command should be aware that it may do unexpected things.
* The current approach is expecting a `bash` command, so perhaps limiting the usefulness e.g. on Windows, but IDK.

We could have a `gftools build` command, that would collect a couple of common build steps. That way we could be more secure and more portable and we could remove a lot of boilerplate from the build command above. A bit similar to what we see in the setup for GitHub Actions. Each possible step would be reviewed by us and could be used optionally (order could be configurable, having a dependency tree based implementation would be awesome). It would be cool if there would be an existing tool that we can use and just fill with content. Also, even `gftools build` tool would have limitations compared to just running any script, but that's the whole point.

Other suggestions are welcome, something simpler would be cool. ;-)

cc @santhoshtr, @davelab6, @m4rc1e, @chrissimpkins, @felipesanches