Make Python version an input in check-manifest and linting action

[sfmig]

Description

What is this PR

• Bug fix
• Addition of a new feature
• Other

Why is this PR needed?
Right now, the linting and check-manifest actions are set to run on Python 3.10. It is a bit annoying to manually change this here as we move through supported versions.

With this PR, the Python version for these two actions becomes an input variable with a default value. The default is set to 3.x, which means the latest stable version of Python 3. This seems more convenient and is also more consistent with the build_sphinx_docs action and the test actions.

What does this PR do?
It sets the python-version variable as an input for the lint and check_manifest actions.

References

This came about from a discussion in movement regarding what does it mean when we say we support a specific Python version.

Right now, when we say we support a specific Python version (say 3.12), in practice we mean we run the code tests in Python 3.12. But we don't check in CI if the developer tools (linting and check manifest) also run on Python 3.12 (because it is manually set to 3.10 and we cannot pass it as an input).

More generally, should we treat the developer tools we test on CI the same way as we treat tests? That is, should we ensure that the CI actions related to precommits run all the supported Python versions? @niksirbi mentions in movement for the development enviroment we recommend the middle one of the three supported Python versions at any given point. Is this a widespread convention?

How has this PR been tested?

\

Is this a breaking change?

If we want backwards compatibility with the current situation, we could make the default value 3.10.

Does this PR require an update to the documentation?

\

Checklist:

• [ n/a ] The code has been tested locally
• [ n/a ] Tests have been added to cover all new functionality
• [ n/a ] The documentation has been updated to reflect any changes
• The code has been formatted with pre-commit

[niksirbi]

I'm happy for this to go through as is.

@niksirbi mentions in movement for the development environment we recommend the middle one of the three supported Python versions at any given point. Is this a widespread convention?

To clarify, this is a convention I just arbitrarily came up with, I don't think it's widespread thing. Perhaps developing on the latest supported version for each package makes more sense?