ci: add WinGet publishing for releases

[DevTwilight]

Please check if the PR fulfills these requirements:

• The commit message follows our guidelines.
• You tested the changes.

Related issue (if applicable): #239

What kind of change does this PR introduce?

This PR adds automatic WinGet publishing support to the release workflow.

Does this PR introduce a breaking change?

No.

New feature or change

• Added a WinGet publishing job to the release workflow.
• Automated WinGet package updates after releases.

What is the current behavior?

Releases are published to GitHub Releases, but WinGet package updates are handled manually.

What is the new behavior?

WinGet package updates are automatically submitted after a successful GitHub release.

Other information

The WinGet publishing job runs after the GitHub release job completes successfully.

[DevTwilight]

any update on this i was hoping for it with 0.25.0

[NathanLovato]

Same status, the priority is bug fixing and generally nailing the formatting. While known bugs are open I'll generally prioritize them. And with little free time I can only get to a limited set of things.

[DevTwilight]

I get it. If I were a member, I could help with things beyond code as well—merging smaller PRs that are piling up, helping with setup, and taking care of other maintenance tasks to help reduce the workload.

[NathanLovato]

Thanks for trying to help. The bulk of the workload is things that require quite a bit of time and a good familiarity with the codebase. For the most part, it's tasks that anyone could do, but that require a lot of personal investment. Typically careful work on the code, code reviews, a lot of manual testing... For the most part it's things that don't require write or maintainer access. But these are not things that I will ask of anyone. If someone does volunteer and, for example, starts contributing bug fixes, of course, I will gladly review and merge them in priority, and this definitely saves time if done well.

Contributions toward automated publication or features like the wizard UI or GDExtension are great too, I appreciate them very much. They just end up slightly behind in priority. Primarily because this is a formatter first and foremost, and code formatting should work correctly and the program should have the least negative impact possible on people's work. But hopefully, that part is mainly a matter of time, especially as GDScript is not growing or changing much anymore syntax-wise.

[NathanLovato]

Superseded by #352 (freshly merged, contained this PR's code)