[stable2412] Backport: github/workflows: add ARM macos build binaries job (#6427)

[EgorPopelyaev]

Description

This PR adds the required changes to release polkadot, polkadot-parachain and polkadot-omni-node binaries built on Apple Sillicon macos.

Integration

This addresses requests from the community for such binaries: #802, and they should be part of the Github release page.

Review Notes

Test on paritytech-stg solely focused on macos binaries: https://github.com/paritytech-stg/polkadot-sdk/actions/runs/11824692766/job/32946793308, except the steps related to pgpkms (which need AWS credentials, missing from paritytech-stg). The binary names don't have a darwin-arm identifier, and conflict with the existing x86_64-linux binaries. I haven't tested building everything on paritytech-stg because the x86_64-linux builds run on unbutu-latest-m which isn't enabled on pairtytech-stg (and I haven't asked CI team to enable one), so testing how to go around naming conflicts should be covered next.

TODO

• [x] Test the workflow start to end (especially the last bits related to uploading the binaries on S3 and ensuring the previous binaries and the new ones coexist harmoniously on S3/action artifacts storage without naming conflicts) @EgorPopelyaev
• [x] Publish the arm binaries on the Github release page - to clarify what's needed @iulianbarbu . Current practice is to manually publish the binaries built via release-build-rc.yml workflow, taken from S3. Would be great to have the binaries there in the first place before working on automating this, but I would also do it in a follow up PR.

Follow ups

• [ ] unify the binaries building under release-30_publish_release_draft.yml maybe?
• [ ] automate binary artifacts upload to S3 in release-30_publish_release_draft.yml

[github-actions[bot]]

This pull request is amending an existing release. Please proceed with extreme caution, as to not impact downstream teams that rely on the stability of it. Some things to consider:

• Backports are only for 'patch' or 'minor' changes. No 'major' or other breaking change.
• Should be a legit fix for some bug, not adding tons of new features.

• Must either be already audited or not need an audit.

  Emergency Bypass

  If you really need to bypass this check: add validate: false to each crate in the Prdoc where a breaking change is introduced. This will release a new major version of that crate and all its reverse dependencies and basically break the release.