CI: disable to build fix/* and feature/* branches

[q4a]

It looks like CI is running too often. If we make it as rule to create small branches as a fix/* or feature/*, then these changes will help reduce/speed up the build.

Here is docs about CI branches: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-including-branches-and-tags

[espkk]

This is actually the reason why I triggered it only for develop :)
Though it would help, I'm wondering if we really need to build anything except develop until it's not in the PR?
If you need this for your fork, I think you can modify this CI script in the develop branch of your fork... at least I read this in the actions manual.
So what's the case and how should we proceed?

[q4a]

The problem can be if you are developing in branch dxvk-* (like me) or coas-remastered (like @Hammie) or Speed-Infuence-On-Cannons-Aiming (like LipsarJ).
To add this branches in CI each developer will have to change CI, but not everyone knows where is it located and how it should be changed.
At the same time, after changing the CI, developer must push it to github and then do not forget to exclude this changes if developer wants to make the PR directly from his branch to upstream develop

General idea - firstly to let other developers to focus on C++ changes with working CI and secondly think about extra CI builds.

[q4a]

Excluding 2 branch names (fix/* or feature/*) seems like a reasonable compromise between the extremes: building everything or building only develop. If there are other proposals for the golden mean - I'm ready to discuss.

[mitrokosta]

Correct me if I'm wrong, but I think only storm-devs org members can directly push to the repo? If that's the case I think we should trigger CI by default only for develop branch and educate all storm-devs members on how to include their branch in CI. Outside contributors have to work with forks and PRs anyway, so nothing changes for them.

[Hammie]

I like this idea, so I would approve it, but I don't have a strong preference either way.

[espkk]

Well... can someone look through GitHub Actions docs? there should be something to indicate the upstream
I think we can do two jobs, one for the forked repos to simplify contributors' life, and another for the upstream with reverted #311

[q4a]

Check this PR: #327