feat: input for zizmor-version

[vgelbgras]

This pull request adds configurability to the Zizmor tool version in the check-actions-security GitHub Action. Instead of always installing a fixed version, users can now specify which version to use via an input parameter.

Enhancements to Zizmor version control:

• Added a new input parameter zizmor-version to action.yml, allowing users to specify the desired Zizmor version (default remains '1.16.0').
• Updated the installation step to use the specified Zizmor version, passing the version dynamically via an environment variable.
• If the input is empty the latest version is installed

Tests:

• Without defining the zizmor-version input

• With the input set to 1.17.0

• With the input set to an empty string to use the latest release of zizmor

[SMoraisAnsys]

Thanks for the proposed changes @vgelbgras

I don't have a strong opinion on allowing (or not) this new input. I would avoid allowing to use the latest version of zizmor through an empty string though. While I like the idea, it leads to running code that maintainers haven't had the chance to look into before running. Since we are moving toward pinned versions in CI and controlled versions, I would avoid that.

As for my though on the new input:
Pros:

• would allow one to use a newer version of zizmor that isn't yet added to the ansys/actions latest release
• would allow one to use a newly release version of ansys/actions (which contains zizmor bump and leads to required changes) while postponing temporarily the changes required to work with a new version of zizmor until one has the time to tackle them.
  Cons:
• if one does pin a version, one can easily forget about it and this would lead to the use of an old version of zizmor without knowing it :/ This is probably the most critical part as it partially defeats the purpose of this action..

Note, we could add a "check" mechanism that triggers a warning if the version used is lower than the default version.

[vgelbgras]

Thanks for the proposed changes @vgelbgras

I don't have a strong opinion on allowing (or not) this new input. I would avoid allowing to use the latest version of zizmor through an empty string though. While I like the idea, it leads to running code that maintainers haven't had the chance to look into before running. Since we are moving toward pinned versions in CI and controlled versions, I would avoid that.

As for my though on the new input: Pros:

• would allow one to use a newer version of zizmor that isn't yet added to the ansys/actions latest release
• would allow one to use a newly release version of ansys/actions (which contains zizmor bump and leads to required changes) while postponing temporarily the changes required to work with a new version of zizmor until one has the time to tackle them.
  Cons:
• if one does pin a version, one can easily forget about it and this would lead to the use of an old version of zizmor without knowing it :/ This is probably the most critical part as it partially defeats the purpose of this action..

Note, we could add a "check" mechanism that triggers a warning if the version used is lower than the default version.

Hi @SMoraisAnsys, I removed the part to use the latest version if the input is an empty string
For saf teams, the interest of using the input version is to sync the version with what there is in the .pre-commit-config.yaml file