Add ban-types rule

[armano2]

I ported this rule and tests from tslint, additionally i added some extra tests to check more cases

this rule relies on changes from #174

[bradzacher]

Question here for a general consensus.
Do we want to 1 for 1 implement the tslint rule?

First:
It seems to me like the configuration is a bit ugly with arrays of arrays.
It's error-prone and unintuitive.
Would prefer something like:

{
  "types": {
	"String": "Use string instead", // custom error message
    "Foo": null // default error message
  }
}

Second:
Do we want to add a fixer to this rule?
I personally think that we should endeavour to add fixers to as many rules as possible.
Esp if the general use case for this rule is to prevent usage of a type, there's probably an alternative.
In this case we could add a config option to specify the alternate type.

[armano2]

@bradzacher yup, i was thinking about this, but i decided to keep interface as is in tslint, i can change it :>
changing options is going to cleanup code https://github.com/bradzacher/eslint-plugin-typescript/pull/181/files#diff-0242bc852e8543fc636ee062b862330bR44 is converting it to this format

fixer will be nice but it will require users to specify to what they want to change it.
how to you want options to look like with fixer?

{
  "types": {
     "String": "string",
     "Foo": null
  }
}

maybe we can change interface a little that, when user is not allowed to specify message, but replace string?

[armano2]

@bradzacher i updated options to follow first of your suggestions

[bradzacher]

great work!

Maybe add a third option which is an object config?

{
  "Foo": null, // no custom error
  "Bar": "Bar is deprecated, there is no direct replacement", // custom error only
  "String": { // custom error and an optional fixer!
    "message": "Use string instead",
    "fixWith": "string" // nullable, in case there is no fix...
  },
}

What do you think?

I'm not sure - depends on our intention with this rule.
Is it purely for flagging things that can't be used, or is it about suggesting alternatives for things?

If it's about forcing alternatives, then having the null, and string-only options is counter-productive, because it allows people to not see the fixer option (and it makes your code slightly more complex).

If it's purely for flagging, then the 3 option style is best.

[armano2]

we can add support for all 3 syntaxes, it's not going to be hard, just few ifs.

[armano2]

@bradzacher i added support for all 3 of them :>

[bradzacher]

two minor nits, otherwise LGTM - great work

[bradzacher]

Almost forgot - don't forget to update the root README.md!
Fix the tests, address the nits and we can merge this

[armano2]

this rule relies on changes from #174

and all tests should pass when #174 is merged