docs: mention that python requirements need to be specified using ful…

…l address from the root (#21293)

It may be not so obvious that referring to the Python requirements using
their "regular" path produced by the `list` goal will not be compatible
with the format expected in the `[tool].requirements` field, see
https://www.pantsbuild.org/2.21/reference/subsystems/ruff#requirements:

```
$ pants list 3rdparty/python | grep "flake8"
3rdparty/python:flake8#flake8
...
```

The target should be referred to as `requirements =
["//3rdparty/python:flake8"]`. If it's not (e.g. using
`3rdparty/python:flake8`), then an error is raised:

```
$ pants lint ::
...
ValueError: Invalid requirement '3rdparty/python:flake8': Parse error at "'/python'": Expected string_end
```

The reqs might be in the form of VCS requirements that resembles the addresses (with colons in between), see https://pip.pypa.io/en/stable/topics/vcs-support/. So the // prefix is to help to differentiate between those.

src/python/pants/backend/python/subsystems/python_tool_base.py

@@ -124,7 +124,9 @@ def _install_from_resolve_help(cls) -> str:
 
             Values can be pip-style requirements (e.g., `tool` or `tool==1.2.3` or `tool>=1.2.3`),
             or addresses of `python_requirement` targets (or targets that generate or depend on
-            `python_requirement` targets).
+            `python_requirement` targets). Make sure to use the `//` prefix to refer to targets
+            using their full address from the root (e.g. `//3rdparty/python:tool`). This is necessary
+            to distinguish address specs from local or VCS requirements.
 
             The lockfile will be validated against the requirements - if a lockfile doesn't
             provide the requirement (at a suitable version, if the requirement specifies version