This brings scratch-gui in line with the rest of the scratch-* packages, and what scratch-www needs for the project preview page.

build in production mode on travis

Unfortunately this will purge unnecessarily after gh-pages deployments, but that should not be an issue.

Currently using an unmerged PR in gh-pages. (Will update to an LLK fork if we decide to go this way.)

Move to Travis build stages to handle the multiple deploy methods by branch.

Stop "testing" in more Node versions than 6, as this is basically just testing our build tools (using a single Node version simplifies using build stages.)

Also add a `watch` command for testing static build output.

This allows gh-pages to work. Something changed in the precise VMs that prevents the git clone gh-pages uses from working correctly.  See https://github.com/travis-ci/travis-ci/issues/4942

On my fork, this change allowed the gh-pages deploy to succeed.

This version of babel-loader dropped support for Node < 4. Although 4.2 >= 4, update to 6  for consistency with our other repos, and so that we stay ahead of the curve for any other packages.

Add missing file types to `.gitattributes`.
Use `node` instead of deprecated `stable` version specifier for Travis.
Set dev tool to `cheap-module-source-map`.

Otherwise npm ignores devDependencies

This improves React performance by skipping prop type checks and warnings

Makes local deployment easier

`npm update` does what we want and is less hacky than removing the packages entirely first.  Specify latest as the version so we always get the latest version even though I erroneously installed scratch-blocks@0.1.0.

Once another project uses this package, these should become peerDependencies.  Until then install automatically.

With only one concurrent build, we can't wait for all the jobs to finish first