Instead of using a GitHub Actions-specific shell script to initialize
the shell variables `MSYSTEM` and `PATH`, we now use the standard
`/etc/profile` file. This file is already written by the `please.sh
create-sdk-artifact minimal-sdk` command.

This is the first step to unlock a more general process where the
`minimal-sdk` artifact is made available for wider use by continuously
releasing ready-to-consume archives.

Signed-off-by: Johannes Schindelin <[email protected]>

Nowadays, 64-bit Windows no longer means Intel in general; It could also
mean Windows/ARM64.

Let's start here with naming CPU architecture-specific things by the
actual CPU architecture, rather than by how many bits its addresses
have.

More precisely, let's use i686 for 32-bit Intel, x86_64 for 64-bit
Intel (excluding Itanium, which is not supported by Git for Windows),
and aarch64 for 64-bit ARM.

Signed-off-by: Johannes Schindelin <[email protected]>

Taking a page out of MSYS2's book where they release their `srcinfo`
artifact continuously, by replacing the file in the release at
https://github.com/msys2/MINGW-packages/releases/tag/srcinfo-cache, we
publish the minimal SDK artifact to the `ci-artifacts` GitHub release.

It is slighly tricky because GitHub's REST API does not allow to replace
an existing asset atomically, so we have to delete the old one first.

To keep the window small where the asset is not available, we first
upload the new asset to a temporary name, then delete the old one, and
finally rename the new one to the old name.

Signed-off-by: Johannes Schindelin <[email protected]>

Whenever we update the rolling release, we want to point to the revision
corresponding to the new artifacts, i.e. from which they were built.

Signed-off-by: Johannes Schindelin <[email protected]>

Since `.tar.gz` has its preferred habitat safely outside the Windows
world, let's also provide a `.zip` version of the artifact, and for
good measure even a self-extracting 7-Zip archive (which can be run
everywhere, without having to rely on PowerShell or a native `tar.exe`).

In my tests, both sizes and extract times vary greatly depending on the
used file format. Here are manual measurements as of time of writing:

        .tar.gz     .zip        .7z.exe
Size    95.7MB      84.2MB      41.6MB
Time    4.1s        4.3s        11.1s

Note that I used the native Windows `tar.exe` that is available in the
`C:\Windows\system32` directory which is a BSD tar and comes
preinstalled with Windows build 17063 and later; It is vastly faster
both in extracting `.zip` and `.tar.gz` files (sadly, it has no support
for `.7z` archives) than the corresponding MSYS utilities `unzip` and
`tar` distributed with Git for Windows.

In any scenario where all three formats can be extracted (with roughly
the same speeds as in my tests), and where Defender does not need to
scan the downloaded `.7z.exe` file first (which added up to 8s in my
testing), it therefore depends on the available bandwidth when fetching
from Azure Blobs (where GitHub release assets seem to be stored
nowadays) which one is preferable. At download speeds above 6MB/s, the
`.zip` archive is the fastest to download and extract, below that, the
self-extracting 7-Zip archive provides the best overall speed. Obviously
this should be measured in each particular use case instead of basing
any decision on above-mentioned numbers.

Signed-off-by: Johannes Schindelin <[email protected]>