Fix duplicate error message for literal union types

[erdinccurebal]

Fixes #63050

Problem

When assigning a non-enum union of string/number/bigint literals to an incompatible type, the error message would display the same information twice. For example:

declare const x: "a" | "b"
const y: number = x

Previously produced:

Type 'string' is not assignable to type 'number'.
  Type 'string' is not assignable to type 'number'.

The union "a" | "b" was generalized to string, which is identical to the per-member elaboration (each member also generalizes to string), resulting in a duplicate message.

Fix

In reportRelationError, after computing the generalized base type, check whether the source is a non-enum union whose members all share the same base type (i.e., the generalized form is a single non-union type). In that case, skip the generalization for display purposes so the error shows the original literal union instead:

Type '"a" | "b"' is not assignable to type 'number'.
  Type 'string' is not assignable to type 'number'.

The two lines now provide complementary information: the first shows what the type is, the second shows why it's incompatible.

Unions with mixed base types (e.g. 1 | "" → number | string) are still generalized as before, since the generalized form differs from any single member's elaboration.

Baseline changes

Three existing baselines are updated — all had duplicate messages that are now fixed:

• typeOfOperator1: typeof x result union was generalized to string, duplicating the elaboration
• bigintPropertyName: 6n | 7n | 8n (type alias Q) was generalized to bigint, duplicating the elaboration
• complicatedIndexedAccessKeyofReliesOnKeyofNeverUpperBound: "text" | "email" was generalized to string, duplicating the elaboration

[erdinccurebal]

@microsoft-github-policy-service agree

[typescript-bot]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate