Record Flow type improvements

[mwiencek]

Fixes #1722

I moved the Values type parameter to Record<Values>, so calling Record(foo) can infer Values from foo and now returns RecordFactory<Values>.

This is a breaking change, though I believe it provides much better type checking for typical uses (and fixes at least one TODO). Unfortunately, this PR introduces issues when calling RecordInstance methods from a subclass (which I'm not sure how to fix), but that probably isn't super common, so the tradeoff might be worth it.

[mwiencek]

With the new changes, Flow doesn't like the this & TPerson return type one bit:

Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ type-definitions/flow-tests/record.js:155:12

Cannot return this.set(...) because: [incompatible-return]
 • Either RecordInstance [1] is incompatible with this [2].
 • Or TPerson [3] is incompatible with this [2].

     type-definitions/flow-tests/record.js
 [3]  147│ const PersonRecord = Record<TPerson>(defaultValues);
         :
      152│   }
      153│
 [2]  154│   setName(name: string): this & TPerson {
      155│     return this.set('name', name);
      156│   }
      157│ }
      158│

     type-definitions/immutable.js.flow
 [1] 1659│   set<K: $Keys<T>>(key: K, value: $ElementType<T, K>): this & $ReadOnly<T>;



Found 1 error

[mwiencek]

I'm not sure what the use case here is (and PersonRecord is no longer parameterized anyway) so I removed the test altogether. If someone can explain the use case I can perhaps update it instead. :)

Edit: To be clear, the test right above this one is now class Person extends PersonRecord, so it's "without types" (though that isn't really possible anymore) now, and the .get('unknown'); there errors, which I think is correct, but which contradicts this test (at "Note: no error").