Build automatically using GitHub workflow

[Semphriss]

Yet another feature that made me think that if it's useful for me, there's a chance it might be useful for others :)

This uses GitHub Actions to automatically build w64devkit.

---

This is the way I made it for myself, I'm open to bring modifications to the PR if something in there would be interesting.

The builds are triggered on either of two events:

1. Each commit pushed to master, and each pull request open to master, which upload builds to the Action page (example):
   
   This offers a nice an easy way to download builds for any commit on the master branch. Unfortunately, those are only available for logged in users.

2. Each tag pushed on the repo, which automatically uploads the builds to a new release marked as draft (example - the only thing I did manually was to publish the release):
   
   This offers a ready-made template for releases based on git tags. I tried to strictly follow the format used by the latest releases, as to minimize manual intervention, but the release is not automatically published by GitHub Actions, so manual intervention is always possible before publishing a release.

---

The upsides I've noticed:

• The builds happen on GitHub rather than on my machine, so I don't have to wait 30 or so minutes per build before my machine becomes usable again (or before I can power it off and switch OS).
• The builds run in parallel on GitHub, because it uses one VM for each architecture-flavor pair. Locally, each build would have to be done one at a time, or the machine's cores would be divided between each concurrent build.
• It allows effortlessly seeing when a PR or a commit breaks the builds, and in the case of PRs, it allows the author of the PR to notice those errors by themselves without needing active feedback from others.
• It offers a reliable, somewhat reproducible (or at least well-documented) environment to build w64devkit in. Also, in situations where it might be an issue, there's no need to trust that anybody didn't tamper with the files.

The downsides:

• It takes 1h30 to finish all builds, and no download is available before all builds finished. For single configurations, building locally may be faster. However, for an all-configs build (6 configs * 30 minutes per config on average = 3 hours total), GitHub Actions remains faster.

---

If there's interest in this PR, I can explain in further detail any decision I took while creating the workflow file. I'm also willing to adapt this PR as necessary.

[Peter0x44]

I'm using this, it's useful for me. It needs minor adjustments now though, there isn't a -mini version any longer.

[Semphriss]

@Peter0x44 I've updated the script and rebased on master.

The workflow still doesn't use the multibuild.sh script, since steps would need to be extracted to make them fit in GitHub's file format. There are still a few minor differences between the script and the workflow file, notably about the version suffix. I preferred to leave it like that since it makes the maintenance of the workflow easier, but I'm open to update it as necessary.