Error on conflict between npm shrinkwrap and modern lockfiles

Update changelog

Add $STACK to the cache signature

This reduces the wall-clock time from 16 minutes to 9 minutes.

Previously new apps (or apps where the cache has been cleared using
the heroku-repo plugin) would give a skipping cache restore message
of "new-signature" which was slightly misleading.

To ensure that the cache is busted when apps update to a new stack.

Fixes #445.

If the user has not specified a version for npm, but there is a package-lock.json we should automatically install npm 5

Fixes #422

Error out when two different lockfiles are present in the repo

Fixes #410

Update changelog

- Log every time the compile succeeds
- Add log information about which build scripts are being used

The buildpack should bust the cache whenever the PREBUILD boolean changes
to prevent the user from caching their local node_modules directory

Fixes #399

If a user pushes a source tree that already includes .heroku/node, give
a nice warning instead of a crypic error message.

Fixes #371

* Make yarn available to application if defined in engines

Fixes #402 

- Drop testing support for Cedar-10
- Add testing support for Heroku-16

Fix link to shunit2

* instrument basic metrics
* remove extraneous failure count
* better warning and failure hierarchy
* remove strict unset check to be compatible with stdlib

This reverts commit dd6a5f5a.

Warnings that mention npm installs can be confusing if you're using yarn to install your dependencies.

Prepend 0 to auto-computed WEB_CONCURRENCY values

When customers run Node together with PHP or Python, then Node's .profile.d/ script will set a WEB_CONCURRENCY variable depending on dyno size. The Python .profile.d script (due to alphabetical order) and the PHP "boot scripts" then see a WEB_CONCURRENCY value and use it, as they cannot know that the variable was set not by a customer using heroku config:set, but by another buildpack's dyno .profile.d/ script.

This change prepends a leading zero to the WEB_CONCURRENCY variable set by the Node buildpack, which the Python and PHP buildpacks can detect and choose to ignore, but should not affect customers using the variable.

JS has some weirdness with leading zeros being interpreted as octal, but that doesn't appear to affect us here.

run tests with yarn if available