* Fix yarn run error when script is empty string

Currently the `build` step gets jumbled up with the `npm install` step. Let's cleanly separate the two

This generates random uuids for both each build run, and the app itself. It then propagates the app uuid through each subsequent build by serializing it into the cache.

This isn't completely ideal because PR apps will each get their own app uuid, but it should still allow us to do better analysis on our log data than we currently can.

Questions like "How many apps failed yesterday?" vs "How many builds failed yesterday"?

The build uuid helps make sure that we aren't ever double counting events somehow.

Adds a cross-platform compatible command to generate `uuid`s

Currently we're tracking the time spent in parts of the build process, like installing `node_modules` or running the build command, but we're not tracking how long the whole build takes. Let's fix that.

Also removes a stray `new-build-script-opt-in` call that wasn't doing anything

This makes sure that even in the case where a `heroku-postbuild` script is completely empty, it will still be preferred over the `build` script.

* Add warning for the upcoming run build change

Make sure that failing builds in CI actually fail

Automatically make the metadata from the previous run available by copying it at the start of the build. This will be used to provide better failure messages.

Bring in the new build metadata module and add calls to store this info in the cache

* Add timing function to builddata module

* Add rest of non-test bash to shellcheck

* Add rest of lib/* to shellcheck

* Add lib/failure.sh to shellcheck

* Add lib/environment.sh lib/json.sh to shellcheck

* Add lib/dependencies.sh to shellcheck

* Add lib/build-data.sh and lib/cache.sh to shellcheck

* Make lib/binaries.sh pass shellcheck

* Add shellcheck to rest of bin/* scripts

* Add bin/compile to shellcheck check

* fix: handle case where memory.limit_in_bytes is nonsensically large

In certain CI environments, this value can be misreported, resulting in an invalid initial `MEMORY_AVAILABLE` value. In these cases, we default the max detected memory to 16GB, or slightly larger than a `performance-l` instance.

Add new module for storing build metadata

* [kvstore] wrap string with spaces

* Add monitoring for binary installations

Add warning for flatmap-stream 404 failure

This is a pre-requisite for making better use of the cache.

The current cache layout puts everything that the Node buildpack wants in the cache at: $CACHE_DIR/node including custom directories.

This creates a naming issue, since a user could cache anything. We currently keep a cache signature at: $CACHE_DIR/node/signature, but if a user declared a custom cache of a signature file, these would conflict and break things.

Adding anything else to the Node cache would make this problem worse, so let's fix it.

This adds one more level where all of the cached directories can live. Now if a user wants to cache a signature file, the cache layout would look like this:

node/
  - cache/
    - signature
  - signature
so there is no longer a conflict.

Deploying this will cause a cache miss for all users since the new code is looking in a new spot, but this is a common enough occurrence that I don't expect it to be significant for anyone. To ensure that the old cache will be discarded, I've added a version to the signature file.

This checks the user's package.json for a heroku-run-build-script key. If it is set to true the new build step will be run instead of the old step, and a message will be printed at the beginning of the build to confirm that is the case.

This adds a new logic branch that will run the 'build' script by default, and run the 'heroku-postbuild' script instead if it is defined.

This branch will not be run for any user yet. Further changes will start to enable this.

* Update default version to new Node LTS version v10.x

* Add Node 11 integration tests and metrics plugin

These tests use >= version requirements, so they would break whenever
new major versions are released. That's not really necessary, so this
removes the bits that will continually break.

Now that 1.11.0 is released with https://github.com/yarnpkg/yarn/pull/6413 merged,
Heroku users should see fewer failed builds due to 500 responses from
the registry.