Scope and structure of this repository, godot-build-scripts and build-containers

I was about to reply in godotengine/godot#75401 when this repository was created, so let's continue the dialogue here.

For context, the motivation of godotengine/godot#75401 was not only to provide tip/nightly/latest builds of godot's master branch in binary format. That's the foundation for providing container images that game/app developers can use for building, testing and deploying their projects in CI (see godotengine/godot-proposals#1411). There should be containers available for both *master* and stable releases, so they can use the same flow for testing upcoming changes in the tool and for generating the releases with stable versions. For instance:

```yml
- uses: docker://ghcr.io/godotengine/export:master
with:
args: --export-release '${{ matrix.preset }}' '${{ matrix.path }}'
```

In godotengine/godot-proposals#1411, the assumption was that maintainers would need to create a user in docker.io and setup the secrets. However, that's not the case anymore. Nowadays, the default `github.token` allows pushing containers to `ghcr.io/godotengine` (which is the "Packages" section of this organisation: https://github.com/orgs/godotengine/packages). Therefore, it's only a matter of deciding in which repository we want to have the workflow that builds and pushes the containers.

In reply to https://github.com/godotengine/godot/pull/75401#issuecomment-1485729418, I was to ask whether the correct approach would be to have a workflow execute scripts from [godot-build-scripts](https://github.com/godotengine/godot-build-scripts) using containers from [build-containers](https://github.com/godotengine/build-containers). None of those repos has any CI workflow. The default registry in them is `registry.prehensile-tales.com`, but I don't know whether that's the official registry used for hosting the images used to generate official Godot releases. I believe it would be sensible to have a (maybe weekly or monthly) workflow for building containers from `build-containers` and pushing them to ghcr.io/godotengine/build. Then, have another workflow to run godot-build-script and push to ghcr.io/godotengine/editor and ghcr.io/godotengine/export.

In this context, I saw godotengine/build-containers#96. I agree with merging build-containers and godot-build-script being sensible. Both have very little content and traffic, are tightly related, and having separated bugtrackers does not provide much benefit. It might be named `godot-builds`. Since GitHub supports having multiple decoupled workflows in a single repo, the one building the images would be independent from the one using them.

Then, this repository was created. Currently, it provides redirects to artifacts. As a result, a GitHub login is needed. That's not a problem in GitHub Actions, because the default token allows read access to artifacts. However, in order to retrieve those nightlies from e.g. GitLab, credentials need to be managed. Conversely, neither containers nor release assets do require any login at all. Therefore, although this is a nice foundation (particularly given how long it took to bring it up :heart:), I believe we should evaluate how to improve it in relation to build-containers and godot-build-scripts.
Assuming that those two repos are merged into godot-builds, and that we use those to build proper (with regard to flags, signing, etc.) nightly (daily) binaries, would it be feasible to publish them as release assets of that secondary repo and make this page point to those? Should then this page/repo be also merged into godot-builds as the frontend?

Summarising:

- Two workflows need to be created in order to automate building nightly artifacts of the same "quality" as the regular releases. Shall those be contributed to godot-build-scripts and build-containers? Or shall those two repos be merged first?
- Is this repo to be considered standalone or is it to be merge into godot-builds along with the two other?

For context, MSYS2 has been using dummy pre-release assets to host temporary/staging packages for two years now. See [msys2/msys2-autobuild](https://github.com/msys2/msys2-autobuild), [github.com/msys2/msys2-autobuild/releases](https://github.com/msys2/msys2-autobuild/releases) and https://github.com/msys2/msys2-autobuild/tree/6788467670f5ce71e62db593c2960f051e457f76#automated-build-process.