CI - Updated version handling

[Aidan63]

This has all been far more CI stuff than I initially bargained for, but here's one more before I lose the will to CI or forget it all.

This is mostly a cleanup of the auto incrementing version stuff to avoid using the ci run counter and my workaround I added the other day. The logic is as follows.

• The last tag is fetched and compared against the version number in haxelib.json
• If the major and minor versions of the two match then the patch number of the tag is incremented and used as the next tag / version number
• If the haxelib.json major / minor combination is newer than the last tag then the haxelib version is used with the patch number set to zero.
• Any other version comparison results are treated as failures.

This means we still have the incrementing patch number for releases and by updating the version in haxelib.json we can reset the patch counter for new major / minor releases. E.g. changing the haxelib.json version to 5.0.x will result in the next release being 5.0.0 instead of 4.3.whatever.

I also updated some of the CI actions used since several of them were depricated and going to be disabled in November. This is a bit hard to confirm that it works, but by modifying the yml before opening this merge I was able to create releases in my fork.

[Aidan63]

Seeing as one of the mac haxe test suite actions got stuck I've just downgraded it to use macos-13 (x86) to get it to run again and get a speed up. Once all parts of the haxe puzzle have a native arm version I'll revisit to see if its still really slow.

#1121

[Simn]

This PR now has a conflict.

[Aidan63]

@Simn updated to master