Additional cases for prop-types and no-unused-prop-types

[alexzherdev]

So I was adding test cases to both rules to bring them to parity after the refactoring, but a couple of things didn't make sense.
In particular, having just one flag for ignoring props validation doesn't seem to be enough (and that was the case before the refactoring as well). For instance, let's say we encounter a spread in props e.g.

type Props = {
  ...data,
  lastname: string
};

That means any this.props.foo usage is considered to have a corresponding propType and it's ignored in prop-types via ignorePropsValidation flag we set in the helper.
However, this shouldn't preclude us from being able to detect whether lastname is an unused propType in no-unused-prop-types (this would be ignored if we met a {...props} spread). But we can't rely on the same flag, because that flag means a different thing. So I'm proposing to split it into two.

Also see comments inline.

Resolves #836

[alexzherdev]

Similar to the case with propTypes, if the shape contains a spread plus some properties e.g.

type Props = {
  person: {
    ...$Exact<BasePerson>,
    lastname: string
  }
};

it would be unwise to throw away the information we have about lastname just because we have a spread. By setting an additional flag and leaving the children data in place, we can detect if lastname is being used.

[alexzherdev]

So these tests are now able to detect that lastname is not used. I understand this is a breaking change? Not insisting on any of these to go in, but seems like a good change to me.

[ljharb]

I think we could consider it a bug that the rule missed it previously.

[ljharb]

Can these new test cases also be added that don't use flow?

[alexzherdev]

Sure. Wanted to start with a smaller set to validate the idea.

[alexzherdev]

Travis is flakey.

[ljharb]

Indeed; don't worry about those errors, I habitually rerun them when i see them.

[alexzherdev]

It’d be great if this could get merged before I push the used prop type refactoring, as they’re slightly interrelated.

[ThiefMaster]

I think this also fixed #1885 and #1473