Respect hard-coded buildpacks

[jmorrell]

If I want to test the Ember buildpack with a new version of the Node buildpack, then a reasonable assumption would be that I could do that by:

heroku buildpacks:clear
heroku buildpacks:add --index 1 https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/emberjs.tgz
heroku buildpacks:add --index 2 https://github.com/heroku/heroku-buildpack-nodejs#custom-branch-name

However we currently always point to the production version, which gives me no way of doing that without modifying the buildpack directly and deploying two forked buildpacks:

https://github.com/heroku/heroku-buildpack-emberjs/blob/master/buildpack/mrblib/buildpack/commands/compile.rb#L22

It also means that customers have no way of pegging the Node buildpack to a specific version in case of a conflict or to opt into a new feature such as we did for yarn support.

[jmorrell]

cc @hone

I'd be happy to work on this, but I'd probably need some hand-holding with the ruby 😨

[edmorley]

This buildpack has been deprecated (c06c1e3), and it's also no longer possible for changes to be made to it, due to the issues mentioned in #61.