[CI] Automate preparation of release binaries for publishing (via artifacts)

[cameel]

Closes #9933.
Depends on #12173 (draft until it's merged). Merged.

It's not complete automation of the publishing process as stated in #9933 but it at least takes care of the most tedious and error prone part of the process so I think it's good enough.

The PR adds:

• A script for downloading artifacts representing the binaries we use in releases.
  • Surprisingly there's no command for easy downloading of artifacts inside a CircleCI job and it requires using their API (see Access uploaded artifact URL in job). Fortunately I already had a script for doing something similar (Script for downloading release binaries from github solc-bin#41) so I repurposed it for this.
• The c_release_binaries job that uses the script to gather artifacts from jobs that build release binaries, puts them in two directories (one for github release, one for solc-bin) and names files in each directory according to our naming conventions. Then attaches the results as its own artifacts.
• A step that posts a notification to gitter when it succeeds.
• A small fix for missing *workflow_trigger_on_tags in some of the existing jobs. Merged separately.

The new job is supposed to run only on tagged commits. Note that I can only really test it on a PR. On a tagged commit some things will be different (CircleCI env vars, version string, etc.). We'll have to test that in practice once the PR is merged.

[cameel]

This passed CI. Here's a successful run of b_release_binaries and a message posted to gitter (slightly misformatted because the variable containing tag name is not defined on a PR).

Now I'm removing the temporary commits - the job will only run on tags from now on.

[cameel]

This is now reviewable too.

[ekpyron]

Wouldn't it be easier, cleaner and safer to rename the binaries in the respective builds already and attach them to a common workspace similar to what we do for the bytecode run?

[cameel]

Not necessarily easier but might be doable. The biggest issue is that I need to get all binaries in the workspace but under different paths. You get an error if a job depends on multiple jobs adding a workspace file under the same path. Doing it via artifacts does not have this problem.

When I started this PR I actually did not understand our workspace layout all that well. It's often mounted at different locations in similar jobs and not in a consistent way. It was really confusing to me and I tried to clean that up in #12450. Unfortunately this resulted in a conflict between binaries on Linux and macOS now that the paths are consistent.

But after working on it I think that the current gnarly layout would work without a conflict. So yeah, I'm going to try to redo it like that.

Another option I was thinking of was rewriting the Bash script here in Python. In #12818 I already have a Python module with helpers for CircleCI and Github API so this would replace the big script in this PR with something much smaller. But if the workspace solution works, maybe it's better.

[ekpyron]

Yeah, I know the problem with path conflicts in merging workspaces... but I thought since we have the same problem with the bytecode comparison runs, it may just work or at least not be too hard to achieve, but not entirely sure...

[cameel]

Yeah, you must be right. t_bytecode_compare does attach the workspace so it should work. It's just that I did not realize that at first and thought that trying to do it via workspace would be very messy and require renaming binaries. I only see now that it shouldn't :)

[cameel]

We should really clean up the workspace layout though. Once we do this, we will have a conflict. My current idea to sidestep that is to name each binary after the platform and use symlinks in #12450.

[leonardoalt]

Waiting for answer from @cameel

[cameel]

Answered. Basically, I need to decide which way to go with this and update it one way (workspace) or another (Python-based script).

[cameel]

Closing in favor of #12929.