Avoid Python patch version in engine hash (pantsbuild#19784)

This fixes pantsbuild#19781 by ensuring the engine hash (as computed by
calculate_engine_hash.sh) only uses the implementation, major version
and minor version, not the patch version (e.g. `cpython 3 9` instead of
`Python 3.9.17`. Before this, the patch version could differ between
runners on CI, and that would change the engine hash, leading to jobs
attempting to rebuild the engine.

This is motivated by the assumption that the engine only depends on the
CPython ABI version, which is the same for all patch versions, and thus
having the hash change based on the patch version is unnecessary.

GitHub seems to upgrade the Python versions across runners in phases,
meaning `actions/setup-python` with a version specifier of `3.9` will
sometimes be 3.9.17, and sometimes 3.9.18. When the the engine is built
with one version, and then a test job has a different version, the test
job would notice the mismatch in engine hash and start rebuilding the
Rust engine. See pantsbuild#19780 for verification of this.

This explains why CI has been failing inconsistently: sometimes we get
lucky and all jobs run with the same Python version, but often we don't.

This is one approach to fixing pantsbuild#19781, that's probably better than
pantsbuild#19783.

(Only one of this and pantsbuild#19783 needs to merge.)

build-support/bin/rust/calculate_engine_hash.sh

@@ -35,7 +35,8 @@ function calculate_current_hash() {
       echo "${MODE_FLAG}"
       echo "${RUST_TOOLCHAIN_CONTENTS}"
       uname -mps
-      "${PY}" --version 2>&1
+      # the engine only depends on the implementation and major.minor version, not the patch
+      "${PY}" -c 'import sys; print(sys.implementation.name, sys.version_info.major, sys.version_info.minor)'
       git ls-files --cached --others --exclude-standard \
         "${NATIVE_ROOT}" \
         "${REPO_ROOT}/rust-toolchain" \