Does not support multiple Windows architectures at the same time

As pointed out by @dsanders11 and discussed in the last Ecosystem WG meeting (cc @erickzhao @toinane), this project causes problems for applications supporting multiple Windows architectures, due to how [Squirrel.Windows](https://github.com/Squirrel/Squirrel.Windows) works and the features offered by GitHub Releases.

## Summary

If multiple architectures for Windows are supported, the latest build to post its files to GitHub Releases will be the active one. This problem is seen on Electron Fiddle. If x86 is published after x64, then any x64 application will silently and automatically update to x86. The problem is exacerbated by the fact that Electron Fiddle now supports Windows for ARM. If such build is the latest one to be published, the setup of all non-ARM users is suddenly broken.

## Problem

Using Squirrel.Windows to package an application typically results in 3 artifacts:

- The setup executable used for first-time installs. This binary includes the architecture on its file name.
- The nupkg package for updates (with or without deltas). This ZIP includes the architecture on its file name.
- A `RELEASES` text file that includes the name to the nupkg package.

When an Electron.js application tries to auto-update itself, it asks update.electronjs.org for the latest `RELEASES` file. If the contents described there are different from what the local user has, then the corresponding nupkg is downloaded and the auto-update process kicks-in.

GitHub Releases offers a simple flat bucket for files. When multiple Squirrel.Windows builds targeting different architectures are uploaded to the same GitHub Releases entry, the latest `RELEASES` file to be uploaded takes precedence, whether that file corresponds to the right architecture or not.

## Common Solutions

What people typically for proprietary apps (including Postman) is to include the architecture in the URL where the `RELEASES` file is uploaded. However, this strategy is not possible using GitHub Releases given its flat structure.

## Proposed Solution

I believe there is a path forward that is backwards-compatible and does not require making significant changes to Squirrel.Windows, which is currently unmaintained and not taking any further PRs. I'll take Electron Fiddle as an example, but the solution should work for any Squirrel.Windows-powered app.

- Modify packaging tools that make use of Squirrel.Windows such as `electron-forge` to output both a `RELEASES` file and a `RELEASES-` file. We will be using the latter, but the former is kept for backwards-compatibility.

- Modify the HTTP endpoint provided by update.electronjs.org to redirect requests for the `RELEASES` file to the corresponding `RELEASES-` file on GitHub Releases. If such file is not there, fallback to `RELEASES`. The server knows which architecture is requested as such information is present on the URL.

Given these changes, an app like Electron Fiddle will publish `RELEASES-x64`, `RELEASES-x86` and `RELEASES-arm64` files and update.electronjs.org will resolve requests for updates correctly. The changes to i.e. `electron-forge` would be considered minor changes and most people using this service will be upgraded automatically.

What do you think? Its a pity we have to change various components to make this work, but I can't think of a better way that preserves backwards-compatibility without introducing significant changes to Squirrel.Windows (and potentially releases a major version of it).