Present somehow to user that literal type is a widening literal type

[normalser]

I'm just adding the task here for your consideration (because it was buried in a comment in some other bug).

With #11126

we have now (literal types and widening literal types) and new rules to remember to understand the resulting inferred type for mutable location:

Type	Inferred type for mutable location
'foo'	'foo'
widening 'foo'	string
'foo' | 'bar'	'foo' | 'bar'
'foo' | widening 'bar'	string
'foo' | widening 'foo'	'foo'

etc..

Now using this code:

// File: SomeonesLibrary.ts
declare var val:boolean
export const a : 'a' | 'b' = (val) ? 'a' : 'b'
export const b = (val) ? 'a' : 'b'

// File: OurCode.ts
import * as test from './SomeonesLibrary'

// VSCode will show:
// test.a -> type: 'a' | 'b'
// test.b -> type: 'a' | 'b'

let a1 = test.a // Type: 'a' | 'b'
let a2 = test.b // Type: string  --->> why ??????? 
       // not easy to answer without going to source code of someones files 
       // to understand TS behavior


// Assume user did not check what TS infered for `a1` and `a2` because 
// natural thinking is that it is of type `a | b`
a1 = 'c' // Throws error nicely
a2 = 'c' // No error shown 

so what I'm asking is - make it more clear for user to figure out why TS behaves in a way it behaves (because right now presenting Type: a | b for both cases is misleading and can cause some bugs (or rather prevent bugs from detecting)

Maybe VSCode could show:

// test.a -> type: 'a' | 'b'
// test.b -> type: widening 'a' | widening 'b'     # or different color 

Thanks a lot for consideration

[RyanCavanaugh]

I'm not sure this reduces net confusion, but we can consider it

[RyanCavanaugh]

It's not at all obvious what value this would provide -- anyone capable of understanding what that would mean probably wouldn't be confused in the first place, whereas anyone who doesn't know what widening "foo" means is going to be really lost