IsStringLiteral: Fix instantiations with infinite string types - #1044

Fixes #1032

Found a really nice trick to solve this! Refer to the code comments explaining how it works:

This fix will make this type quite useful because almost all string utilities will require an IsStringLiteral check. For example:

import { Split, Words, StringSlice } from "type-fest";

type T1 = Split<Uppercase<string>, "">;
// Actual: [Uppercase<string>]
// Ideal: string[]

type T2 = Split<`${string}-${string}`, "">;
// Actual: [string, "-", string]
// Ideal: string[]

type T3 = Words<Uppercase<string>>;
// Actual: []
// Ideal: string[]

type T4 = Words<`${string}-${string}`>;
// Actual: [string]
// Ideal: string[]

type T5 = StringSlice<Uppercase<string>>;
// Actual: ""
// Ideal: string[]

I'll open up a separate PR fixing all the above mentioned cases.

I've mentioned the same as an example in the documentation:

NOTE: If IsStringLiteral is instantiated with a union of literal strings and non-string types, it currently returns false because not all union members are literal strings. However, after this PR, cases like these would instead return boolean.

type T1 = IsStringLiteral<null | "a">
//   ^? type T6 = false // Current behaviour

type T2 = IsStringLiteral<null | "a">
//   ^? type T6 = boolean // Updated behaviour

To me, the current behaviour seems more like a bug than an intentional choice, as returning boolean makes more sense and allows users to decide how to handle mixed union cases.