This PR refactors how the coverage tool is handled in the toolchain
registration.

1. Instead of creating the repo during the macro evaluation of
   python_register_toolchains, we are creating the coverage hub repo
   pypi__coverage separately in a macro that mimics the pip.parse
   extension. This is done as part of py_repositories call that is
   used by WORKSPACE and bzlmod users.
2. We accept @rules_python//python:none label as the sentinel value of
   no coverage tool so that the user can define a select statement that
   when no coverage tool is defined a special value is passed.
3. We reuse the bzlmod hub_repository for the coverage hub repo.

I think dog fooding the pkg_aliases and hub_repository a little more
is a nice thing and I might refactor the deps in the future to do that for
the whl_library and pip_compile deps. What is more I have a theory that
it may be possible to wire a py_console_script_binary as the coverage tool by
doing the following:

1. Move the definition of the py_runtime out of the python_repository. I am
   not sure if this is a pre-requisite to avoid circular deps. Maybe we don't
   have to do this step.
2. Install coverage_py via pip_parse/pip.parse as a regular thing.
3. Use py_console_script_binary to create a single executable.
4. Modify the py_binary to create a single executable file (I think there is
   a ticket for this).
5. Use rules_platform to transition the py_console_script_binary into a
   binary with values = {"collect_code_coverage": "false"}. That way we would
   introduce a py_runtime of one configuration to be a dependency of a different
   configuration.
6. By this time, should we have a separate coverage toolchain?

This refactor was partially inspired by the recent #2599 and #2597.