CI's should be split into their own repository to save on time and costs

Original issue description

Like the title states, all CIs, but GitHub Actions, should be split into a separate repository and mentioned in the projects (this repo) README. The initial goal was twofold: 1. Showcase how [Rust](https://www.rust-lang.org/) can be used to create true, native, cross-platform apps. 2. Showcase how said apps can be built on practically every CI platform. However, there are two main problems with this: 1. A single PR is checked through multiple times by different services. Runtime varies, but GitHub Actions seems to be the fastest and most reliable (as of writing this). Any PR has to wait on a grand collection of different CIs and potential CI-specific issues. While not all are required for a merge (only the GitHub Action ones are actually looked at by myself, mostly), it still gives a bad taste to outsiders looking at the PR having something like "6 successful (<- GitHub ones), 20 failed ones (<- external/3rd party ones)" (<- possibly exaggerated). 2. "Cost". Not only does waiting time suck, most CIs only give you X amount of minutes per Month (or request ... which adds another layer of complexity for myself) and with that many projects this is easily used up in a single day. > Plus, a bunch of other issues such as notification spam that if a single PR fails I am getting like ~20 mails notifiying me about my build failed. Yes, I could disable notifications, but there is no easy way to check 3rd party/external providers for notifications direclty from GitHub. Meaning I would have to check every platform on it's own, separately. Possibly creating even more work. The proposed better way is a win-win situation: 1. PRs will **only** be checked with GitHub Actions. 2. GitHub Actions will be the **single** point of truth. 4. All other CIs will be moved to external projects. 5. All other CIs will be mentioned in each project (starting with this base project). 6. All CI-Projects can be easily used by simply cloning (or forking) the projects and copying (or using a subtree, possibly submodule) This also should reduce complexity in case of dependency changes, upgrades/updates, and so much more. There are only two downsides, I am seeing ATM with this approach: 1. Adding a given CI to a clone/fork requires the extra step of adding it now. I don't think this is a huge issue though, as most CIs require you to login/register anyway, activate/load the project, confirm the pipeline, etc. I.e. manual work is **already involved** and copying or adding a subtree/submodule configuration should be the smallest task here. 2. It would be basically impossible to create a working CI config for all projects. While most will work fine, there are some special projects (like the Bevy or the Vulkan projects for example) which need additional libraries and setups. A write-up to what needs to be changed from the CI configuration can be added to our README easily though, and additionally the GitHub Actions file can be linked as a reference (as most CIs function roughly the same with small syntax changes anyway).

closes #195

SakulFlee / Rust-Multi-Platform-Project-Template

CI's should be split into their own repository to save on time and costs #196

Codecov Report