Update Caffe and Soda workflows

[xioren]

The objective is to homogenize and simplify the various runner workflows as well as bring them up to date. This brings Caffe and Soda in line with Vaniglia and hopefully makes the process of maintaining easier. It is dependent on this pull request.

Several open issues can be closed with this. #53, #3067, #216

Known Issues:

• fastsync was switched off for Caffe as it prevented compilation (missing winesync header)
• Soda was compiled against proton_8.0 as experimental_8.0 currently has an upstream bug.
• I experienced permission issues when creating a new tag during workflows but I assume this is an issues with my fork.

Next Steps:

• Utilize scripts for programmatic selection of version numbers (as Vaniglia does). They are hard coded as it stands.

This pull request needs scrutiny. Also I wasn't sure if this should be directed at stable or master so I have a separate (closed) pr for master if that is preferential.

Sorry at @ you @mirkobrombin but you seem like the only one maintaining this repo and thus the only one able to review.

[xioren]

Resetting workflows.

[mirkobrombin]

Hi, thanks for your contribution.

Currently we used different branches for different runners; stable is for Vaniglia stable, master for Vaniglia unstable, then soda for Soda stable, caffe for Caffe stable, cx for Crossover Wine stable.

For Soda and Caffe we use an old Arch Linux release to build (which was the only distro working with TKG in a while) and downgrade the repository to obtain an old gcc version since the resulting runner builds could be not compatible with recent gcc versions.

I didn't take a look at the new workflows yet. Does them solve/follow the above?

I am fine with merging everything in a single branch and handle different builds with different workflows.

[xioren]

I am happy to redo the pull request with each in their own branch. As for the builds, I use the existing environment.sh and updated environment-tkg.sh (separate pull request). Soda and Caffe both build successfully so I am not sure if or why a GCC downgrade would still be necessary unless there was some issue with the built runners I am not aware of.

[mirkobrombin]

Nice! Sorry I didn't explain it well, the problem with gcc is not building but running the resulting build in some distributions, e.g. the flatpak runtime.