[FIX] [no-unused-vars] address more false positives

[brainkim]

Fixes false positives demonstrated in these test cases (type parameter in new expression, type parameter constraints):

import { Nullable } from 'nullable';
class A<T> {
    bar: T
}
new A<Nullable>();

import { Nullable } from 'nullable';
import { SomeOther } from 'other';
function foo<T extends Nullable>() {
}
foo<SomeOther>();

import { Nullable } from 'nullable';
import { SomeOther } from 'other';
class A<T extends Nullable> {
    bar: T;
}
new A<SomeOther>();

import { Nullable } from 'nullable';
import { SomeOther } from 'other';
interface A<T extends Nullable> {
    bar: T;
}
const a: A<SomeOther> = {
    foo: "bar"
};
console.log(a);

[brainkim]

updated to deal with new expressions and class type parameter constraints

[JamesHenry]

@brainkim I am very sorry for the long delay in coming back to this, we are going to work out a better maintenance plan for this project.

I have been merging PRs in order, and I'm afraid that means there are new conflicts for your PR

[brainkim]

Rebased the PR against master. Unfortunately, I decided after a while to stop using this rule b/c I kept running into false positives. Instead, I'm setting "noUnusedLocals" and "noUnusedParameters" in tsconfig to true.

Two additional cases which may or may not have been fixed since I worked on this:

this type in arguments:

function foo(this: Bar) {
  return this.type === "bar";
}

will throw an error saying this is unused.
public/protected/private keywords in constructor arguments:

class Foo {
  constructor(public: bar, private: baz) {}
}

will throw an error saying bar and baz are unused.

[brainkim]

#150 <- related issue.
We might want to create a meta-issue for dealing with all no-unused-var false positives.

[bradzacher]

unfortunately no-unused-vars is a difficult rule to maintain due to how many cases typescript introduces.

Thanks for your help in catching more edge cases