Prepare release artifacts for Windows as part of CI

[SimplyDanny]

SwiftLint's release steps are fully automated. The Windows build(s) must be made part(s) of the release workflows.

Things to clarify beforehand:

1. Which build artifacts do we need to provide? Just the executable? An installer?
2. Which Windows versions to provide pre-built binaries for?
3. Is the executable allowed to load SourceKit at runtime or do we only provide a fully statically-linked binary that supports only SwiftSyntax-based rules (like we provide a separate static Linux executable)?

[roman-bcny]

Installer is standard, some projects also like to include a portable zip file.

Probably just need x64 and arm64 versions of the exe, supposedly shouldn't need multiple variants of these.

@compnerd need guidance regarding 3. SourceKit

[compnerd]

Yes, the executable is allowed to load SourceKit at runtime even with static linking. SourceKit is C/C++, so that should be fine and you don't need to worry about ODR violations due to the multiple Swift runtimes.

[SimplyDanny]

The reason I connect static linking with the exclusion of SourceKit is due to the fact that both coincide on Linux with musl not providing dlopen and dlsym.

I so guess that this is not the case for the Windows static-linking mode?

[compnerd]

Correct, Windows gives you the ability to slice through things as you wish. The current SDK, even with static linking, forces dynamic linking of the C/C++ runtime. You can dynamically link any of the other libraries that you like, and you can also use LoadLibraryW for dynamically loading any library that you would like.