Revert to simple 'pyXY' factors

[stephenfin]

What's the problem this feature will solve?

Starting in tox 4, tox uses virtualenv's PythonSpec.from_string_spec to parse factors for Python version info. This replaces the homegrown regex-based approach used previously ([1], [2]).

tox 4 brings many advantages and sets us up nicely to take advantage of big changes in the Python ecosystem, especially those drive by PEP-517 and PEP-660. In this one area though, I think we've made a mistake. The regex used by PythonSpec.from_string_spec is extraordinarily permissive. It encourages use of periods in factors, which is something was not supported previously, and breaks the idea of factors being delimited by hyphens to support factors by encouraging things like py37-64 (for a 64 bit build of the CPython 3.7 interpreter). None of these changes are things I feel we should support, let alone encourage.

In tox 3, the list of valid factors looked something like this:

• py (effectively meaningless by nonetheless supported)
• py2 (use whatever python2 points to)
• py3 (use whatever python3 points to)
• py4 (for when Python 4 is a thing)
• py38
• py311

These were all self explanatory. In tox 4, this list is massively expanded:

• py3.10
• py3.10.1
• py3.10.1-64
• pypy3.10.1
• cpython310
• ironpython3
• 3
• 3.10.1
• ...

It also presents some oddities. For example, py3-64 will be parsed as a single factor indicating that a 64 bit build of python3, but other things like py3-16, py3-1, py3-9 will be parsed as two separate factors with no special meaning for the numeric suffixes. All of this feels magical and makes describing what a factor is very difficult.

This is the direct cause of #2657 and has been raised as a point of confusion in other issues and PRs.

Describe the solution you'd like

Revert to the previous behaviour of simple factors such as py3, py310, pypy2, or jython3. We can and should continue to use PythonSpec.from_string_spec to parse the factors that we have identified as Python factors as well as parsing values in base_python. Encourage users who want more control over their Python version to set base_python for the testenvs in question.

Alternative Solutions

N/A.

Additional context

None.