)

Add `<micro>` version to the target platform. Instead of `cpxy_os_cpu`
the target platform string format becomes `cpxy.z_os_cpu`. This is a
temporary measure until we get a better API for defining target
platforms.

Summary:
- [x] test `select_whls` function needs to be tested to ensure that the
  whl selection is not impacted when we have the full version in the
  target platform.
- [ ] `download_only` legacy whl code path in `bzlmod` needs further
  testing.
- [x] test `whl_config_setting` handling and config setting creation.
  The config settings in the hub repo should not use the full version,
  because from the outside, the whl is compatible with all `micro`
  versions of a given `3.<minor_version>` of the Python interpreter.
  This means that the already documented config setting do not need to
  be changed.
- [x] `pep508_deps` tests for handling the `full_python_version`
  correctly.
- [x] `pep508_deps` tests for ensuring the `default_abi` is being
  handled correctly.

Fixes #2319

(cherry picked from commit 1e21dbd)

This has been fixed in the Starlark implementation in bazel-contrib#2793 and in this
PR I am backporting the changes to handle the full python version
target platform strings so that we can have the same behaviour for now.

At the same time I have simplified and got rid of the specialization
handling in the Python algorithm just like I did in the starlark, which
simplifies the tests and makes the algorithm more correct.

Work towards bazel-contrib#2830

Handling of `python_full_version` correctly has been fixed in the
Starlark
implementation in #2793 and in this PR I am backporting the changes to
handle
the full python version target platform strings so that we can have the
same
behaviour for now.

At the same time I have simplified and got rid of the specialization
handling
in the Python algorithm just like I did in the starlark, which
simplifies the
tests and makes the algorithm more correct.

Summary:
* Handle `cp3x.y_os_arch` strings in the `platform.py`
* Produce correct strings when the `micro_version` is unset. Note, that
we use version `0` in evaluating but we use the default version in the
config setting. This is to keep compatibility with the current behaviour
when the target platform is not fully specified (which would be the case
for WORKSPACE users).
* Adjust the tests and the code to be more similar to the starlark impl.

Work towards #2830

Handling of `python_full_version` correctly has been fixed in the
Starlark
implementation in #2793 and in this PR I am backporting the changes to
handle
the full python version target platform strings so that we can have the
same
behaviour for now.

At the same time I have simplified and got rid of the specialization
handling
in the Python algorithm just like I did in the starlark, which
simplifies the
tests and makes the algorithm more correct.

Summary:
* Handle `cp3x.y_os_arch` strings in the `platform.py`
* Produce correct strings when the `micro_version` is unset. Note, that
we use version `0` in evaluating but we use the default version in the
config setting. This is to keep compatibility with the current behaviour
when the target platform is not fully specified (which would be the case
for WORKSPACE users).
* Adjust the tests and the code to be more similar to the starlark impl.

Work towards #2830

(cherry picked from commit 9e613d5)