Improve reliability of package publishing

[imiric]

We're currently in the process of moving from Bintray to a self-hosted environment for serving our DEB/RPM/MSI packages (https://dl.k6.io/). This is based on a set of shell scripts and syncing to AWS S3 (#1916, #1964).

We'd like to improve the reliability of this process in two ways:

1. Ensure that the process and combination of tools is robust in order to avoid surprises during the actual release, which could be weeks or months apart. We use a pre-built Docker image to stabilize this somewhat, but the process itself could fail in surprising ways.

   To address this it would be good to publish unstable packages on merges to master, as suggested by @na--, which would happen much more frequently so we would be testing the process often. Whether this should be done to a separate bucket/environment (https://dl.staging.k6.io/ ?) or as a separate category of packages (unstable/testing) is up for discussion. These packages could also be suggested to users that need some unstable functionality that's not yet released in a stable release, avoiding the need for them to setup Go and compile their own binaries.

2. Plan a disaster recovery or rollback procedure in case the S3 bucket is corrupted. We could enable versioning, but that only works on a per-object basis, and would be difficult to manage as a global snapshot system. s3-pit-restore seems like a good tool for managing snapshots, so we should consider that, along with having a backup bucket to sync to.