feat(eslint-plugin): add no-magic-numbers rule

[scottohara]

Extends the no-magic-numbers rule from ESlint core with an additional option (ignoreNumericLiteralTypes) to ignore Typescript numeric literal types when checking for magic numbers.

Fixes #99

The new option allows for type definitions such as the ones listed below to be considered valid.

Currently, the base no-magic-numbers rule currently considers these type definitions as errors, despite there being no valid way (at least that I'm aware of) to define numeric literal types that won't violate the magic numbers rule.

Examples of allowed code

/*eslint @typescript-eslint/no-magic-numbers: ["error", { "ignoreNumericLiteralTypes": true }]*/

type SmallPrimes = 2 | 3 | 5 | 7 | 11;   // handles union types

type Step = 1 | -1;  // handles negative numbers

type MeaningOfLife = 42;  // handles single numbers

Please note that this is my first time contributing a TS rule, so if I've missed anything or if there is a preferred way to implement this, suggestions are welcome.

Also note, unsure if this should be a "recommended" rule or not.

[codecov]

Codecov Report

Merging #373 into master will decrease coverage by 0.02%.
The diff coverage is 93.33%.

@@            Coverage Diff             @@
##           master     #373      +/-   ##
==========================================
- Coverage   95.76%   95.74%   -0.03%     
==========================================
  Files          78       79       +1     
  Lines        3493     3523      +30     
  Branches      963      975      +12     
==========================================
+ Hits         3345     3373      +28     
  Misses         53       53              
- Partials       95       97       +2

Impacted Files	Coverage Δ
...ckages/eslint-plugin/src/rules/no-magic-numbers.ts	93.33% <93.33%> (ø)

[bradzacher]

Code itself LGTM. Few (very) minor nits.

Haven't gotten around to doing it for the existing rules yet, but one thing we want to do with extension rules is to stop copying the documentation from eslint.
Whilst it does force users to click through for more documentation, it saves us from having to track changes on eslint master to update our docs.

Could you please change the docs to something akin to following structure:

1. Header
2. Rule details
   1. The description
   2. Link to the existing rule documentation.
3. Rule Changes
   1. Added Options.

Thanks for your contribution!

[scottohara]

Thanks @bradzacher for the positive feedback.

Regarding the docs format, I agree that not duplicating the core docs is a good move; so I've updated the docs with what I believe you were recommending.

Hope I've understood correctly.

[bradzacher]

everything looks good, one last fix.