[relay-compiler]: Union types

There is an "strange" generation of Flow typings depending on how a query is written. I wrote several examples using the `star-wars` schema (see repo).
Mainly: require `primaryFunction` in a "human hero" should not be possible, not that it returns `undefined`, because it does not exists in the `Human` type.

```ts
// required
graphql`
query trialQuery {
hero {
name
... on Human {
homePlanet
}
... on Droid {
primaryFunction
}
}
}
`;

// obtained
export type trialQueryResponse = {|
+hero: {|
+name: string,
+homePlanet?: ?string,
+primaryFunction?: string,
|}
|};

// expected
export type trial4QueryResponse = {|
+hero: {|
+__typename: "Human",
+name: string,
+homePlanet: ?string,
|} | {|
+__typename: "Droid",
+name: string,
+primaryFunction: string,
|} | {|
// This will never be '%other', but we need some
// value in case none of the concrete values match.
+__typename: "%other"
|}
|};
```

In our TS project obtaining strict union typings is required, see issue and discussion: https://github.com/relay-tools/relay-compiler-language-typescript/issues/135

Repo: https://github.com/artola/rc-bug

Implementation reference details: https://graphql.github.io/graphql-spec/June2018/#CollectFields()

I would like to re-check if it is a bug (see repo, at least "case 2").

Start with the star-wars schema examples in the linked rc-bug repository, especially “case 2,” and compare the generated Flow typings with the expected union output. Read the GraphQL CollectFields specification and the linked TypeScript issue and discussion. Done means the behavior is confirmed and either corrected with regression coverage or documented as expected.

Written by the indexing model from the issue text.