Upgrade eslint

[spalger]

Fixes #7609
Fixes #7622

Upgrades eslint and other related dependencies to the latest versions so that we can take advantage of some of the new auto-fixing features while making the transition to babel 6.

The commits are laid out to help the reviewer focus on a single change type at a time. commits mentioning "autofix" were done completely with npm run lintroller and do not need to be as thoroughly checked.

[spalger]

The majority of the rules were fixable with eslint alone, but no-unused-vars was a bit trickier. Since we had so many violations, and I didn't want to go numb fixing them all by hand, I wrote some jscodeshift transforms to help with common scenarios: https://github.com/kreeware/kibana-jscodeshift/tree/master/transforms

[cjcenizal]

This array needs to be defined with the root and a globbing pattern for lint_staged_files.js to pick up the staged files:

    lintThese: [
      '<%= root %>/Gruntfile.js',
      '<%= root %>/bin/**/*.js',
      '<%= root %>/config/**/*.js',
      '<%= root %>/src/**/*.js',
      '<%= root %>/tasks/**/*.js',
      '<%= root %>/test/**/*.js',
      '<%= root %>/utilities/**/*.js',
    ],

[spalger]

Ah, the **/*.js is necessary. Makes sense

[cjcenizal]

We can use ** instead of the root reference, too:

    lintThese: [
      '**/Gruntfile.js',
      '**/bin/**/*.js',
      '**/config/**/*.js',
      '**/src/**/*.js',
      '**/tasks/**/*.js',
      '**/test/**/*.js',
      '**/utilities/**/*.js',
    ],

[cjcenizal]

This is really awesome. I found one bug, and have a few other thoughts:

1. Where are the eslint rule changes documented? Can we add some eslint-config-kibana 0.2.0 release notes? This way I will know what to test for.
2. Per @thomasneirynck 's point, if you fix some linting errors but don't commit the file, then the lint task will pass and we'll end up committing files that violate our linting rules. I guess these should be caught by Jenkins, though, right? The other solution I can think of is to do some sort of check in our linting task: if a file is staged, but has unstaged changes, error out and require the user to stage the changes or unstage the file.

[spalger]

an we add some eslint-config-kibana 0.2.0 release notes?

Eh, there is less than a single page of commits. Release notes are probably overkill

if you fix some linting errors but don't commit the file, then the lint task will pass and we'll end up committing files that violate our linting rules

Unfortunately, preventing this would require a pretty sophisticated grunt task. This limitation has existed since the pre-commit check was introduced years ago and only comes up very rarely, so I'm not convinced it's worth the effort.

[cjcenizal]

LGTM

[spalger]

I'm going to take another stab at this in a new pr, with a basic tool to help transform files