testing/electron: consider supporting multiple versions

Case

Packages that depend on electron don't upgrade to new versions at the same time. For example, right now oss-code is lagging behind the rest, only buildable on electron 31, while signal-desktop already supports version 33. There could be a hypothetical situation where one electron version cannot rebuild all electron-based applications currently in aports.

Proposal

Consider supporting multiple versions, depending on need, of electron. Thus electron would be named electron$major_version, with a default electron package representing the latest version.

Pros

• Software that depends on electron can use the version it actually supports, reducing possibility of bugs
• Package maintainers can upgrade to the electron version that suits them, offloading from electron package maintainer the burden of rebuilding, patching and supervising electron applications when upgrading major versions.

Cons

• Electron takes forever to build, and its sourcecode is massive. Every security upgrade, arriving on a semi-weekly basis, would require rebuilding 2 or 3 electron versions. I've mitigated the sourcecode issue by setting up infra that automatically packs the sourcecode.
• Major versions come out every two months, and support period is 6 months. This development timeline undermines the proposal's usefulness, as upstream applications are expected to keep up, and change electron versions at least every 6 months.
• How often do applications even break between major-releases? In other words, for example does signal-desktop on 31 have a high chance of bugs if it expects 33?

@selfisekai When you were maintainer, did you consider this and does my evaluation hold-up? The crux of this proposal is to figure out a way to share the work in maintaining an electron application ecosystem on Alpine.

@kdaudt The biggest issue is obviously the compute usage, thus I wonder about your perspective being from infra. Obviously, this proposal is moot if our build infra would not be able to keep up. If I implement this, I expect that at most times I would support the two latest electron versions, and only rarely support a third.

I already follow this approach with dotnet, but it is on a yearly release cycle rather than bi-monthly.