Issue title: Change guard-for-in to allow also the prevention of the use of for-in loops in the code
 Issue body: **What version are you using?**
2.3.0

**What did you do?**
Well it is not like I found an issue, more like I would like to add more options to the `guard-for-in` rule.. Currently the rule only prevents `for-in` loops that doesn't have an `if` condition in them.

This may help in not running over all the prototype chain, but doesn't solve the fact that a `for-in` loop [prevents the JIT optimization](https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#5-for-in) for the entire function.

This could be a **major** code optimization booster in some cases!

**What happened?**
Well I don't have this option.

**What did you expect to happen?**
The optimal solution would be to have 2 options for this rule:
1. just like now - you must have an if condition in the rule
2. **Prevent the use of `for-in` all together** - There are just too many cases that most `for-in` loops actually makes, that prevents ALL JIT optimization on the function that contains the `for-in` loop.
   If you truly need to run on all the prototype chain of an object, [just create an **isolated** function that runs `for-in` and disable this rule specifically there](https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#523-the-object-contains-enumerable-array-indices)..<br>
   Probably most of the usages of the `for-in` loop only needs to run on the keys of the object and not really of all the chain, this rule could save a lot of optimization.

 Comments: 
 Comment 0: +1
 Comment 1: I think using `ForInStatement` with [no-restricted-syntax](http://eslint.org/docs/rules/no-restricted-syntax) would address your suggestion. What do you think?
 Comment 2: Well I must say that I never saw this rule and now I'm in love with it!

In my opinion we should still modify the [guard-for-in](http://eslint.org/docs/rules/guard-for-in) rule to have this option since I look at eslint in a lot of cases as a guideline for good js. A lot of js developers doesn't know about this `for-in` limitation and are just harming their code.

Having the option to block this behavior in a rule dedicated to it sounds like good guidance to me..
What do you think?

If we're not on the same page here it is OK by me to close this ticket since the `no-restriced-syntax` gives me the result I needed :-)

 Comment 3: We don't want to have overlapping rules in the core. Also `guard-for-in` is crafted to protect against this very specific scenario. Even its name implies that so I don't think we can add it there.

I'm glad `no-restricted-syntax` solves your problem!

{'source': 'GithubIssues', 'repo_name_with_owner': 'eslint/eslint', 'issue_id': 140365121, 'repo_stars': 21545.0}