New: Add only to RuleTester (refs eslint/rfcs#73)

[btmills]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

This implements RFC73. RuleTester test cases support a new only property to run an individual case or subset of cases for less noisy debugging. We do not implement test exclusivity inside RuleTester, instead relying on the test framework to provide that functionality when we call only().

Is there anything you'd like reviewers to focus on?

1. I made one change from the RFC. Under Detailed Design, step 3, I inserted a new sub-step between i and ii: "If RuleTester[IT] is set and has an only function property, return Function.bind.call(this[IT].only, this[IT])." For users who customize RuleTester.it, this could make only work without any additional configuration, but if their overridden it has an only function property with different semanticts than Mocha's, this step wouldn't work. Are we okay with this change?
2. Because the RuleTester tests override RuleTester.it and RuleTester.only, testing the itOnly getter was complex.

[mdjermanovic]

1. I made one change from the RFC. Under Detailed Design, step 3, I inserted a new sub-step between i and ii: "If RuleTester[IT] is set and has an only function property, return Function.bind.call(this[IT].only, this[IT])." For users who customize RuleTester.it, this could make only work without any additional configuration, but if their overridden it has an only function property with different semanticts than Mocha's, this step wouldn't work. Are we okay with this change?

Makes sense to me, some customizations might "just work". If it doesn't work by itself, they can override RuleTester.itOnly.

[mdjermanovic]

LGTM, great work!

We can revisit the use of this in static accessors later.