Upgrade pipenv and allow users to override the version installed

[sigmavirus24]

Pipenv is still in a state of extreme flux leading to incompatibilities and instabilities between releases. As a result, let's give users a lever to pull when they've chosen the tool but the default version on the platform doesn't satisfy their needs.

Closes #702
Closes #704
Closes #706
Closes #727

--

Note I included the changelog notes after a conversation with @dzuelke yesterday

[hone]

@sigmavirus24 So we don't allow people in the Ruby buildpack to control the version of Bundler b/c the feature set can differ from version to version. If we then want to leverage a new feature like bundle clean or something, that isn't we can't just upgrade for users. Also once this is set, it's likely to not change which can lead to people staying on old versions. This isn't entirely bad, but can harm adoption of improvements. How bad would it be to just upgrade the default version to fix the current set of bugs?

[sigmavirus24]

As mentioned on #727 there are several open bugs with the more recent versions (which fix somethings) that break other things. We're trading off one fix for another set of support issue. Honestly, I think the best functional decision would be to revert the last update of the default version we made, except that affects the format of Pipfile.lock and was the source of several people being unable to build their app on Heroku. The software is just too unreliable at the moment to have a strict default version given the variety of use-cases on the platform right now.

[techalchemy]

@sigmavirus24 the issue with lockfile formats is mainly due to them being compared against Pipfiles (if they can't be parsed at all I'm not aware of those issues or have already forgotten about them)

A large majority of the related complexity comes from python's dependency resolution and packaging challenges, and the backing resolver behind pipenv has been heavily modified for compatibility as a result

We are in the process of rewriting the backing resolver to produce consistent results, and actually have a working implementation which isn't likely to make it into the upcoming release but will likely be in the following one

We are in the process of heavily separating out functionality into various libraries which will make this process easier on you and everyone else who is relying on this in the build process. The resolution algorithm will actually backtrack. If you are locking on the heroku infrastructure you may want to take advantage of dependency caching for speedups and to avoid network calls, since you control the infrastructure it would just require exposing ~/.cache/pipenv/depcache-pyX.Y.json

[CaseyFaist]

Closing this PR - will continue to use pinned version 2018.5.18 without eager upgrade as described in #769