Lock gh actions versions in CI Pipelines

[pmazurek-cksource]

Lock gh actions versions in CI Pipelines

This PR gh actions (exact sha) versions in CI Pipelines.

Recent supply chain attacks in popular tools (Trivy, LiteLLM, axios) are 
concerning. There might be more such attacks.

Most of our CI pipelines that use public actions (in case of Github 
Actions workflows) or CircleCI orbs are not locked versions. This means 
that if any of these packages would be released and would be vulnerable, 
our jobs would pull these vulnerable versions. We need to lock the versions to 
protect ourselfs from these kind of attacks.

The sha commits in PR can be resolved and verified in the following way:

there are lightweight tags and they point directly to a sha commit, 
so we can use the sha of the tag itself.

But there are also annotated tags, which are separate git objects and 
they are pointing to commit and have their own sha different from commit.
 
Get the SHA commit for example for configure-aws-credentials@v4:
git ls-remote https://github.com/aws-actions/configure-aws-credentials refs/tags/v4^{}
result

^{} - is automatically derefrerrencing annotated tag to commit SHA, if
result is empty then the tag is not annotated but lightweight -> then:

git ls-remote https://github.com/actions/setup-node refs/tags/v4

gives you the commit sha directly but for 
configure-aws-credentials@v4
git ls-remote https://github.com/aws-actions/configure-aws-credentials refs/tags/v4
gives us the sha of the tag itself, not the commit. 
That's why we need to try dereference the tag first and dereference is 
empty then sha of tag is sha of commit itself. So verification:
1) if 
git ls-remote https://github.com/<org>/<action> refs/tags/<version>^{}
gives result, use it, if not, then:
2) git ls-remote https://github.com/<org>/<action> refs/tags/<version>
use this result.

Touches: https://tiugotech.atlassian.net/browse/TD-1704

Touches: https://tiugotech.atlassian.net/browse/TD-1704

What is the purpose of this pull request?

Does your PR contain necessary tests?

All patches that change the editor code must include tests. You can always read more
on PR testing,
how to set the testing environment and
how to create tests
in the official CKEditor documentation.

This PR contains

• Unit tests
• Manual tests

Did you follow the CKEditor 4 code style guide?

Your code should follow the guidelines from the CKEditor 4 code style guide which helps keep the entire codebase consistent.

• PR is consistent with the code style guide

What is the proposed changelog entry for this pull request?

* [#<ISSUE_NUMBER>](https://github.com/ckeditor/ckeditor4/issues/<ISSUE_NUMBER>): Describe the purpose of the pull request in a few simple sentences.

What changes did you make?

Give an overview…

Which issues does your PR resolve?

Closes #<ISSUE_NUMBER>.

[pmazurek-cksource]

I will need help with this CI @pomek @jacekbogdanski