rpm: Add RPM packaging support

[LorbusChris]

What it does

Introduce RPM packaging infrastructure for Theia IDE:

• Add theia-ide.spec for RPM builds
• Add vendor-theia-ide-deps.py to generate source tarballs (main source, plugins, and bundled dependencies)
• Support local mock builds and Fedora COPR builds
• Leverage flatpak-node-generator for consistent dependency bundling across build systems

The spec file mostly follows Fedora Node.js packaging guidelines for bundled Electron applications with support for x86_64 and aarch64 architectures. It however uses precompiled binaries for some dependencies instead of rebuilding them with node-gyp, mirroring the flatpak build approach.

Assisted-By: Claude Sonnet 4.5

How to test

On Fedora, install a build from COPR:

dnf -y copr enable lorbus/theia
dnf -y install theia-ide

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

---

Possible followups include:

• create dependency bundles and RPMs as artifacts for releases/tags on this repo
• setting up https://packit.dev RPM build automation on COPR (also possible for PRs).
• setting up OBS (https://build.opensuse.org/) build automation for more distros including openSUSE.
• submitting the package for review and inclusion in Fedora and/or other distros (I'm not aware of any other Electron app currently packaged in Fedora, and guidelines currently require local rebuilds of deps with node-gyp, which this does not do - instead this mirrors what happens in Flatpak builds. A discussion on that should probably be raised when submitting this spec)

[sgraband]

Thank you for your contribution @LorbusChris. While we appreciate your work i personally do not feel like the benefits of supporting an RPM package unfortunately do not outweight the maintenance of it atm.

@JonasHelming @jfaltermeier @ndoschek do you have another opinion?

[LorbusChris]

Hi @sgraband, I totally see your point. However this should be really low maintenance, as the RRM builds can be fully automated. This can done with GH actions, but it can also be done with external services like COPR (via packit.dev) or OBS, and that would give you RPM builds for free (no GH quota impact). Having RPMs around can make life much easier for folks running on such distros.

How about I add the packit.dev CI config here (there'll be some steps a repo admin will have to run through to enable the GH bot app) in the coming days to show you how this is supposed to work, and then you can still decide whether this change is desired or not?

I'd like to note that even without merging this here, RPM builds can still be automated with these changes living elsewhere, e.g. in a separate repo, and I'll probably set up an automated COPR in case this is rejected here.