Issue 4650 Remove unsupported feature selective upgrade

[matteius]

I am proposing via PR we remove the flag --selective-upgrade on several grounds:

• It doesn't work and hasn't for a long time
• The suggestion for people using it are to use --keep-outdated instead.
• There is no documentation for the code path.
• The code path doesn't make sense and exists in overly complex method we aim to simplify anyway.
• It does things like uses Pip feature
  • to-satisfy-only (undocumented, please avoid) - packages are not upgraded (not even direct requirements) unless the currently installed version fails to satisfy a requirement (either explicitly specified or a dependency).
    • This is actually the “default” upgrade strategy when --upgrade is not set, i.e. pip install AlreadyInstalled and pip install --upgrade --upgrade-strategy=to-satisfy-only AlreadyInstalled yield the same behavior.
    • Ref: https://pip.pypa.io/en/stable/development/architecture/upgrade-options/#controlling-what-gets-installed
• the https://pip.pypa.io/en/stable/cli/pip/#exists-action-option usage also doesn't seem to be anything special or make extra sense why its would be needed over --keep-outdated.
• More reasons to follow if necessary ...

The issue

#4650
#4626
#4351
#3461
#2412
And more: https://github.com/pypa/pipenv/issues?q=is%3Aissue+is%3Aopen+selective-upgrade

The fix

I removed the code for --selective-upgrade

The checklist

• Associated issue
• A news fragment in the news/ directory to describe this fix with the extension .bugfix, .feature, .behavior, .doc. .vendor. or .trivial (this will appear in the release changelog). Use semantic line breaks and name the file after the issue number or the PR #.

[matteius]

Putting this one on hold until -- even though this flag isn't really supported, we probably need to support something that does the right thing for selective upgrades now that I realize what --keep-outdated is doing. Will revisit this.

[matteius]

Deferring this for now -- it needs to be revisited, but one user suggested that we keep the functionality and don't support it. I don't love that approach either, but perhaps there is a way to cleanup or understand the implementation/implications in time.