Reword cross-reference to the poetry project (#508)

The key design distinction between pipenv and poetry isn't
the overall scope of the projects, but rather the assumptions
we make about how projects are going to be structured.

pipenv focuses mainly on "git push" and "git archive" style
publication, where there's a private distribution pipeline
between the repo and production systems (e.g. this is
really common in SaaS and embedded systems).

poetry, by contrast, focuses on the case where a pyproject.toml
file is already present, at which point having Pipfile as well (as
`pipenv` requires if you want to use it to manage development
and testing environments) may feel redundant.

source/tutorials/managing-dependencies.rst

@@ -170,9 +170,9 @@ and techniques to see if one of them is a better fit:
 * `hatch <https://github.com/ofek/hatch>`_ for opinionated coverage of even
   more steps in the project management workflow (such as incrementing versions,
   tagging releases, and creating new skeleton projects from project templates)
-* `poetry <https://github.com/sdispater/poetry>`_ for Python developer focused
-  components that are designed primarily for publication to a Python package index
-  (``pipenv`` deliberately avoids making the assumption that the application
-  being worked on will support distribution as a ``pip``-installable Python package,
-  while ``poetry`` based applications rely explicitly on their Python packaging
-  metadata to describe their application structure and dependencies)
+* `poetry <https://github.com/sdispater/poetry>`_ for a tool comparable in scope
+  to `pipenv` that focuses more directly on use cases where the repository being
+  managed is structured as a Python project with a valid ``pyproject.toml`` file
+  (by contrast, ``pipenv`` explicitly avoids making the assumption that the
+  application being worked on that's depending on components from PyPI will
+  itself support distribution as a ``pip``-installable Python package).