Revise pipenv version mixing caveat

[ncoghlan]

pipenv 11 uses the Python in the virtual environment to generate the lock file now, so version differences between the host Python and venv Python are no longer a problem. The caveat should be reworded to:

1. Make sure folks are using pipenv 11+
2. Note that pipenv folks on a single target version, and running pipenv install on a different version may implicitly install extra unpinned dependencies (if requires_python isn't explicitly set in Pipfile). (Alternatively, we could just recommend always setting requires_python, and note that while possible, dependency locking when targeting multiple versions of Python can be a bit tricky due to version dependent dependencies)

[ncoghlan]

@theacodes Maybe we should go with the "just delete it for now" option? If folks running old versions of pipenv comes up as a problem, we could add a new caveat for that rather than amending this one.

[theacodes]

Yeah let's just take it out. We seem to recommend a eager update strategy for tools.

[ncoghlan]

I've pretty much come around to the perspective of the browser developers when it comes to networked software: if a client is allowed to access the public internet, "evergreen" is pretty much the only safe update management strategy (and then you redesign everything else around that policy).