Typescript codegen generates invalid __typename for fragment when using @include

I have a query that in simplified version looks like this:
```gql
query SpecialQuery($includeDetails: Boolean!) {
user {
abilities {
is_able_a
is_able_b
}
...OtherAbilities @include(if: $includeDetails)
}

fragment OtherAbilities on User {
abilities {
is_able_c
}
}
```

Query works fine, types seemed to worked fine too. But after we upgraded to Typescript 3.6, I noticed that `__typename`s are generated incorrectly _(Typescript added more strict type checks on `string` types, so bug in apollo existed before. I just didn't notice it)._

**Intended outcome:**
I would expect to get code generated to look like this:

```ts
export interface HomeMasterQuery_user {
__typename: "User";
abilities: SpecialQuery_user_abilities | null;
}

export type SpecialQuery_user_abilities = SpecialQuery_user_abilities_Abilities | SpecialQuery_user_abilities_AbitlitiesIncluded;

export interface SpecialQuery_user_abilities_AbitlitiesIncluded {
__typename: "UserAbilities";
is_able_c: boolean | null;
}

export interface SpecialQuery_user_abilities_Abilities {
__typename: "UserAbilities";
is_able_a: boolean | null;
is_able_b: boolean | null;
}

```

**Actual outcome:**

But `codegen` output looks like that:
```ts
export interface HomeMasterQuery_user {
__typename: "User";
abilities: SpecialQuery_user_abilities | null;
}

export type SpecialQuery_user_abilities = SpecialQuery_user_abilities_Abilities | SpecialQuery_user_abilities_User;

export interface SpecialQuery_user_abilities_User {
__typename: "User"; // <-- THIS IS INVALID
is_able_c: boolean | null;
}

export interface SpecialQuery_user_abilities_Abilities {
__typename: "UserAbilities";
is_able_a: boolean | null;
is_able_b: boolean | null;
}

```

Please note that `__typename` for abilities are different.

Types generated for fragment itself, are perfectly fine (fragment is in different file in my code).

**How to reproduce the issue:**

Generate typescript definition for similar code, and see `__typename` definitions

**Versions**

I reproduced this issue on `apollo@2.21.0`

Start with the TypeScript code generation path for Apollo 2.21.0 and reproduce the issue using the query and conditional fragment shown here. Compare the generated __typename for the abilities fragment with the expected UserAbilities type; done means the conditional fragment output uses the correct typename and remains valid under TypeScript 3.6 checks.

Written by the indexing model from the issue text.