feat(45679): support 'did you mean' diagnostics for string literal union

[hi-ogawa]

Fixes #45679

This PR adds a new diagnostic message for assignment type error with "did you mean" suggestion.
I made a new if-branch in reportRelationError for the case when source is StringLiteralType and target is UnionType and it tries to find suggestion with the existing utility function getSpellingSuggestion.
So far I only tested with simple examples I can think of, but if more complicated cases are desired, I'm happy to add more.
So please let me know if that's the case.
Thanks a lot!

EDIT:
I thought I could also try to implement codefix service for this "did you mean" suggestion, but it doesn't look so easy since there seems no way of obtaining target type information at the time of getCodeActions in fixSpelling.ts. I might be missing something here, so I would appreciate if there's some advice on this.

[orta]

Looks pretty solid to me.

I think for the codefix you should be able to use checker.getTypeAtLocation(node) to get the type which corresponds to source which should be the union.

Then you should have enough information to re-run getSuggestedTypeForNonexistentStringLiteralType (expose it in the Checker type and make it @internal to be available at the services later)

[hi-ogawa]

Thanks for the comment and tips!
As I look further into codefix, however, I think another stumbling block is that currently diagnostic range is not the mis-spelled string literal but the assigned identifier (or the property key), as in the test case:

    type T1 = "string" | "number" | "boolean";
    const t1: T1 = "strong";
          ~~
!!! error TS2820: Type '"strong"' is not assignable to type 'T1'. Did you mean '"string"'?

So, unfortunately, implementing this properly would be probably beyond my capacity...

[sandersn]

I like what you have here. Two minor requests.

I looked at the other spelling codefixes. They all work on right-hand sides (rhs) for which the value is misspelled, not the type. It's possible to inspect the assignment's rhs and offer the fix only in the case when it is a value with a unit type. But I don't think that needs to happen in this PR. Let me know whether you'd like to try that.

[sandersn]

very minor: no parens around arrow parameter

Suggested change

	return getSpellingSuggestion(source.value, candidates, (type) => type.value);
	return getSpellingSuggestion(source.value, candidates, type => type.value);

[sandersn]

Currently, generalizedSourceType must === sourceType in this case, but it would be better to use generalizedSourceType here, like the other reportErrors, in case we add some additional processing at the beginning of the function.

Suggested change

	reportError(Diagnostics.Type_0_is_not_assignable_to_type_1_Did_you_mean_2, sourceType, targetType, typeToString(suggestedType));
	reportError(Diagnostics.Type_0_is_not_assignable_to_type_1_Did_you_mean_2, generalizedSourceType, targetType, typeToString(suggestedType));

[hi-ogawa]

@sandersn Thanks for the review! I addressed your feedback in 3dba734.

Thanks for suggestion about codefix as well. But for the codefix feature, I cannot really estimate how it's feasible for me to implement right now, so as you mention, I'd like it to be separate PR from this one if I would even try it. Other contributors might be able to pick it up, so maybe it's better in that way.

If there's anything else I can do on this PR, please let me know. Thank you so much!