Tooling rehaul: introduce ARM64 release; use git tags instead of production branch for releases

[peterdeme]

Description of the change

Tooling rehaul.

Multi-arch uploads to S3 (downloads.spacelift.io)

This pull request makes it so that we'll upload platform-specific binaries to S3 and multi-platform Docker images as well.

How it used to look like:

• https://downloads.spacelift.io/spacelift-vcs-agent
• https://downloads.spacelift.io/spacelift-vcs-agent_SHA256SUMS
• https://downloads.spacelift.io/spacelift-vcs-agent_SHA256SUMS.sig

☝️ Let's call this legacy.

New format:

• https://downloads.spacelift.io/spacelift-vcs-agent-x86_64
• https://downloads.spacelift.io/spacelift-vcs-agent-x86_64_SHA256SUMS
• https://downloads.spacelift.io/spacelift-vcs-agent-x86_64_SHA256SUMS.sig
• https://downloads.spacelift.io/spacelift-vcs-agent-aarch64
• https://downloads.spacelift.io/spacelift-vcs-agent-aarch64_SHA256SUMS
• https://downloads.spacelift.io/spacelift-vcs-agent-aarch64_SHA256SUMS.sig

This naming convention entirely matches the launcher binaries.
❗ We will still upload the legacy files, but we shouldn't use those links anywhere. I'll update the documentation at docs.spacelift.io once this PR is merged.

New release process

A new use-case arose in Spacelift where we'd like to download VCS Agent binaries for Darwin for end-to-end testing purposes. CC @jakubdal
In order to facilitate that, let's improve our release process: instead of merging to the production branch, releases should happen when a new tag is pushed. This follows our other public repositories' pattern such as spacectl or terraform-provider-spacelift.

From now on, Goreleaser will publish a GitHub release whenever a tag is pushed and it'll attach all the built binaries as well.

How does that help us? We will publish all 3 operating systems (Linux/Darwin/Windows) to the GitHub Releases which can be used by endtoend tests - those tests can detect the current OS and architecture and download the agent accordingly.

Type of change

• Bug fix (non-breaking change that fixes an issue);
• New feature (non-breaking change that adds functionality);
• Breaking change (fix or feature that would cause existing functionality not to work as expected);
• Other (miscellaneous, GitHub workflow changes, changes to the PR template);

Checklists

Development

• Lint rules pass locally;
• All tests related to the changed code pass in development;

Code review

• This pull request has a descriptive title and sufficient context for a reviewer. There may be a screenshot or screencast attached;
• This pull request is no longer a draft;

Deployment

• Selected merge strategy is squash merge;
• Changes have been reviewed by at least one other engineer;

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[peterdeme]

@jakubdal ahh there was a typo, fixed it, do you mind reapproving? 🙏

[eminalemdar]

LGTM!