New: Store type parameter constraints (fixes #188)

[Pajn]

Note that Flow uses bound here instead of constraint. I decided to go with a different property because there is some differences between Flow and TS here, however I don't have anything against aligning and require the user to use other ways to distinguish Flow and TS.

[eslintbot]

LGTM

[JamesHenry]

@Pajn would you mind elaborating on the differences? I am not too familiar with how Flow works here

[Pajn]

I don't know much myself, only what I seen via the parser code.
https://github.com/Pajn/prettier/blob/fcc790a2c20e708a5af91a6ec47838b856d9d8e9/src/printer.js#L1786-L1792
The first if that checks n.bound is for Flow and the second that checks for n.constraint is this PR.

As you probably know, a type parameter constraint looks like this in TypeScript

type Result<T extends {}> = Success<T> | Failure 

while in Flow it looks like this

type Result<T: {}> = Success<T> | Failure 

See https://flowtype.org/blog/2015/03/12/Bounded-Polymorphism.html
Flow also supports specifying variance and have some special * syntax. What those really mean and how or if they would effect TS, I have no idea about unfortunately.

[JamesHenry]

Fair enough! Let's stick with constraint then. I am rerunning the build

[JamesHenry]

The build reran successfully and this LGTM, thanks!