As an alternative to python.toolchain.is_default, introduce a
python.defaults tag class with attributes python_version,
python_version_env and python_version_file. This allows to read the
default python version from your projects .python-version files,
similar to other tools. It also allows using an environment variable,
with a fallback if the environment variable is not set.

Label("@@//:.python-version") resolves to the .python-version file of
the root module, if such a file exists.

Implement python.defaults.python_version_env in terms of
module_ctx.getenv, which was introduced in Bazel 7.1. This means that
Bazel 7.0 users who wish to use the new python_version_env will have
to upgrade to Bazel 7.1 or later.

If we read a python_version_file (specified with the defaults tag
class or the default @@//:.python-version file), explicitly start
watching that file. There are some circumstances where such a watch
wouldn't be allowed, but since it's new functionality it doesn't break
anything for anyone to insist on the watch. If a specific use case
requires the relaxation of the requirement, that can always be
considered later.

The idea to read .python-version in the root module was problematic
for two reasons. For one thing, if there is a .python-version file in
the root module, but no BUILD or BUILD.bazel file on the top level, we
produce an error that we can't catch. This would be a breaking change,
requiring users to add a BUILD.bazel file. Also, if the user has a
.python-version file, and also sets is_default on a toolchain, we
would fail the build (or, if we didn't, we'd change the default Python
version against the users explicit instructions). That would also be a
breaking change.

Removing the @@//:.python-version logic means the user needs to opt in
by saying python_version_file="@@//.python-version". That's not
necessarily a bad thing, as being explicit allows anyone to grep the
repo for the label and find out what cares about that file (as pointed
out by @fmeum on Slack; good point).