FR: Produce nightly/wip builds for end-user testing

[thoughtpolice]

While testing #2503, along with the recent performance-related changes that @yuja has been writing, I realized that it would be nice, both for users and developers, to have binaries produced directly from main on a regular basis.

The reason I want this now is because I want to test the musl-linked Linux v0.11 build vs a musl-linked Linux version of HEAD, among other things, to see how ongoing changes to reduce memory use/improve performance are going. That means we'll have both a baseline and a "latest results" to compare against for all our ongoing changes.

Also, doing this also helps ensure changes like #2503 won't accidentally break the release process in some way that won't be discovered until Martin tries to do it, since it uses a whole different workflow entirely than what normal developers do.

Ideally this would use the same release.yml workflow it uses today.

---

Some examples of this I've seen are:

• Creating one on every commit, like wasmtime and buck2 do.
• Do it once a day, instead, at something like 3AM UTC.

In both cases, we should choose a tag like dev or nightly to attach to this build, and overwrite it on every run of this workflow. This has two consequences:

• The tag needs to be regularly force pushed (obviously), and
• We will not store copies of every binary, forever.
  • If we tried to do that, GitHub will eventually reach out to us and tell us to stop.
  • Plus, it clutters up the release page to have prereleases for every commit.

See also: #2483, though they only overlap a bit.

[necauqua]

Github Actions have artifacts which are cleaned up after a little while, the nightly job could just push those - and then we will have convenience links to those somewhere, without any extraneous tags and/or releases.

I fact, those artifacts could be published literally for every CI run (so, PRs), yes