IsStringLiteral: Fix instantiations with infinite string types

[som-sm]

Fixes #1032

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

type-fest/source/is-literal.d.ts

Lines 116 to 122 in 06037a9

	export type IsStringLiteral<T> = T extends string
	// If `T` is an infinite string type (e.g., `on${string}`), `Record<T, never>` produces an index signature,
	// and since `{}` extends index signatures, the result becomes `false`.
	? {} extends Record<T, never>
	? false
	: true
	: false;

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:

type-fest/source/is-literal.d.ts

Lines 97 to 110 in 06037a9

	// This behaviour is particularly useful in string manipulation utilities, as infinite string types often require separate handling.
	type Length<S extends string, Counter extends never[] = []> =
	IsStringLiteral<S> extends false
	? number // return `number` for infinite string types
	: S extends `${any}${infer Tail}`
	? Length<Tail, [...Counter, never]>
	: Counter['length'];
	type L1 = Length<Lowercase<string>>;
	//=> number
	type L2 = Length<`${number}`>;
	//=> number

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.