Add CI setup for packaging Windows on ARM artifacts

[MugundanMCW]

Description:

• The PR introduces CI setup for building and packaging zstd artifacts for Windows on ARM devices
• The CI setup depends on CMake and Visual Studio 2022 for building zstd from source.

[facebook-github-bot]

Hi @MugundanMCW!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[Cyan4973]

A few points :

• CLA signing is a mandatory part of this process. At some point it will have to be fixed for this contribution to be merged.
• The modifications of the Github Action are significant, which makes it difficult to validate through review only. Ideally, we would also need this modification to be tested in CI. It's unusually more difficult in this case, because the modified action is disabled under most circumstances. But we need to find a solution.

One of the options would be to name the feature branch test_artifacts, which should trigger the modified action.

[Cyan4973]

In this naming scheme, build_type can be either msys2 or cmake.
This feels a bit strange, as msys2 is an environment, not a build solution nor type.

Also, pay attention that, within cmake context, build type traditionally refers to something specific, like opt or debug build types.

For clarity of maintenance, I would invite to reconsider this naming scheme.
You probably meant something like shell == msys2 || pwsh, or build == make || cmake.

[MugundanMCW]

@Cyan4973 Thanks for the suggestion, I have replaced built type with shell for better naming scheme and maintainability.

[Cyan4973]

There are more idiomatic ways to state the same thing, with less long-context to maintain,
for example:

- name: Build (MSYS2)
  if: matrix.build_type == 'msys2'
  shell: msys2 {0}
  run: |
    # msys2 commands here

- name: Build (CMake/ARM64)
  if: matrix.build_type == 'cmake'
  shell: pwsh
  run: |
    # PowerShell commands here

I have not yet understood why Powershell pwsh is necessary here, since msys2 also provides cmake.

On the other hand, if both code paths feature a lot of differences, maybe it would be better to just separate them completely into different actions.

[MugundanMCW]

@Cyan4973 Yes, MSYS2 also provides CMake, but currently there's no native MSYS2 environment available for Windows on ARM64. As a result, running CMake within the MSYS2 environment on Windows ARM64 often involves emulation.

[thiru-mcw]

Closing this PR as #4465 is created with the same changes.

Thanks.