[red-knot] Move, rename and make public the PyVersion type

[AlexWaygood]

Summary

Working on #12759 has revealed that we need a general-purpose type that represents an arbitrary Python version (not necessarily one that we support), as well as a closed enumeration of supported Python versions. We actually already have a type like that -- but it's currently buried in red_knot_python_semantic::module_resolver::typeshed::versions. This PR publicly exposes that type, and moves both that type and the TargetVersion enum into a new red_knot_python_semantic::python_version submodule. This will allow the type to be used in #12759, and possibly elsewhere in the future as well.

Test Plan

cargo test -p red_knot_python_semantic

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

Merge conflicts ahead 😆

[MichaReiser]

Should this be TargetVersion?

Suggested change

	/// TODO: unify with the `PythonVersion` enum in the linter/formatter crates?
	/// TODO: unify with the `TargetVersion` enum in the linter/formatter crates?

[AlexWaygood]

The equivalent enum in the linter/formatter crates is called PythonVersion, e.g.

ruff/crates/ruff_linter/src/settings/types.rs

Line 45 in b595346

pub enum PythonVersion {

, and that's what this comment is referring to

[MichaReiser]

We don't need to make this change in this PR but I think it's now a bit confusing when to use TargetVersion vs PythonVersion? Shouldn't all (or at least most) our code be open for new Python versions? Or to phrase it differently, what's the benefit of limiting TargetVersion to a fixed set?

To me, the main reason why TargetVersion is an enum is just that it was easier to reference specific versions. But I think that can also be accomplished by PythonVersion, we can define constants for the versions that we care about (and we can implement Default).

[AlexWaygood]

Hmm, maybe. Having it as an enum is also useful for command-line parsing. But you might be right that we could just use the PythonVersion type everywhere. Not sure; worth experimenting with as a followup, anyway!