String literal apparent types with specific member types - #19846

As mentioned in #19837, calculating the apparent type of union members correctly exposed some undesired behavior with respect to the contextual type produced by the union of a string literal type and an array. The root cause is the index signature in the global string type; so another way to fix the issue is to give string literal type more specific apparent types than the global string type. In this PR, I create a cached apparent type (similar to what we do for intersections) for string literal types which has exact types for the 0 through N properties of the string, based on the text of the literal, and then a more specific index signature based on those types. This also has the nice sideffect of giving you stronger types for ("foo")[2] ("o") or keyof "someLiteral" (all the names on String plus "0" - N; up to the length of the literal.). Only doing this for the apparent type saves us from comparing these properties during relationships, while still giving us the benefits of stronger property types than the indexer on the original apparent type gives.

Fixes #19837