Suggestion: new command to bump versions of dependencies in `pyproject.toml`

• I have searched the issues of this repo and believe that this is not a duplicate.

Issue

It would be awesome if Poetry had a command (let's call it upgrade) that bumped the version constraints of dependencies in pyproject.toml (as opposed to update, which afaict updates the lock file to the newest version within the constraint specified in pyproject.toml).

Some examples for how this command could behave:

• poetry upgrade django: Upgrade Django to the newest version that still works with other dependencies; equivalent to poetry remove django; poetry add django.
• poetry upgrade django djangorestframework: As above, but with more than one package at a time.
• poetry upgrade django=^2.1: Set the version of django to ^2.1, equivalent to poetry remove django; poetry add django=^2.1.
• poetry upgrade: Upgrade every dependency to the newest possible version. Equivalent to deleting the entire [tool.poetry.dependencies] section of pyproject.toml and running poetry add with a list of the names (but not versions) of every package previously in the list. (This one would be good for cookiecutter templates for projects, to make it easy to start a new project with the latest versions of everything.)

Currently, when I want to bump the version of something, I'm either running poetry remove ...; poetry add ... which moves the package to the bottom of the list in pyproject.toml, and results in uninstalling a bunch of dependencies which sometimes just get reinstalled again at the same version; or I'm manually editing pyproject.toml which means I have to look up the latest version manually, and I can't use Poetry's version resolution when I want to upgrade more than one package at a time.

The issue names Poetry's existing update, remove, and add commands plus dependency entries in pyproject.toml, but no implementation files or tests. Start by tracing those command entry points and their version-resolution behavior. Done means the proposed upgrade forms have defined behavior for one, multiple, or all dependencies and are covered by tests for pyproject.toml and lockfile outcomes.