Set up infrastructure to allow for publishing and downloading dev builds automatically

[GeckoEidechse]

The idea would be as follows:

For every commit on main branch we use CI to auto-publish binaries etc to some platform. From there Northstar installers could be used to auto-install the dev build on installer launch for testing. For the player this system would of course be opt in.

For publishing we'd need to add CI to both NorthstarMods and NorthstarLauncher (or figure out another way to listen for changes and create builds). We could add a special "dev" package to Thunderstore that then gets updated with the newest changes from main.

Once on Thunderstore Northstar installers could then pull the files and install them. In the case of r2mm this should be as simple as selecting "Northstar-dev" as your mod instead of "Northstar". For VTOL and Viper they'd have to add support for installing Northstar from Thunderstore first and then add functionality to opt into installing from some "dev channel".

Things to consider:

• [ ] What version number should rolling release dev channel have? It would default to 0.0.0+dev but the issue with that is that using an old dev channel version would bypass version gate. Of course bypassing version gate isn't too difficult but we should avoid making it easy for players to bypass.
• [ ] Given that a change to either Mods or Launcher should trigger new dev build we'd have to duplicate GitHub CI config between both repos (unless there's another way to do it)
• [x] Need support from either or both Viper and VTOL. Dev channel should be mainly installed via auto-update due to frequent changes, so we want at least some of our Northstar installers to support it. Solved by writing my own mod-manager lol
• [ ] Anything else?

[pg9182]

Regarding CI, I recommend allowing the workflow on the main repo to be triggered by a dispatch with optional args for the build number (or commit if we still want to do the build in the main repo, but this is not really a good option since the build process may change too) to use for each repo, where it can pull artifacts (it obviously has to be within the artifact retention time) in from the latest or the specified build of each repo. The dispatch can be triggered by a step in each other repo.

For versioning, one idea could be to add another point number representing the build number (of the main repo), since we don't have a need to strictly follow a 3-part version afaict.

[GeckoEidechse]

Sorta related I realised that at least for release candidates we have like 90% of the infrastructure already in place to do that. The only thing we'd need to set up is an appropriate Thunderstore package and updating CI config to instead of not pushing to Thunderstore on rc, just pushing to a different package instead.