Add eslint-ratchet

[marchuffnagle]

There is a Ruby gem called quality that runs a variety of variety of static code analysis tools against your Ruby code. One of the interesting features of that gem is that it records the number of errors in your code. If you make a change which increases the number of errors, it complains. If you make a change which decreases the number of errors, it records that lower number, and that is the new upper limit. By doing that, it causes the number of errors to trend down over time.

We talked about doing something similar in the Cumulus architecture meeting yesterday to address the large number of eslint errors that are generated in our code. This PR replicates some of the functionality that the quality gem provides.

This PR introduces a bash script called bin/eslint-ratchet. That script runs eslint against your code and determines the number of errors that eslint has found. It also reads the previous best score from .eslint-ratchet-high-water-mark. If there are more errors now than before, it fails and indicates that there has been an increase in the number of errors. If there are less errors than before, it updates .eslint-ratchet-high-water-mark with that new and improved number. That updated .eslint-ratchet-high-water-mark file should be checked into git.

Circle CI also runs eslint-ratchet. It expects the number of errors reported to match the number in the .eslint-ratchet-high-water-mark file. If it does not, it will fail the CI run. That means that you either 1) introduced new errors or 2) forgot to run eslint-ratchet and commit .eslint-ratchet-high-water-mark with the new, lower score.

[scisco]

If this requires a new step in the PR process for every developer, we should update the README and and the PR template