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

use lts range instead of latest

Faster cache and check

remove pure-lockfile

pure-lockfile

typo

removed extraneous yarn lock file

changelog

no need to store these things in the slug

better caching for yarn

check on yarn production incompatibility with npm

ignore engine incompatibilities, this is a dev warning

check npm incompatibility

margins around warning

combined if

tests and implementation for using yarn in place of npm

leave node_modules for caching

use pure-lockfile

use semver.io service to resolve yarn engines

restore original yarn.lock after yarn install

use mktemp compatible with both osx and linux

use yarn check before a --pure-lockfile

use yarn check before a --pure-lockfile

remove yarn check, does not work as documented

clear prebuilt node_modules for yarn users

initial implementation for bin/test and bin/test-compile