Mutability widening for literal types

[DanielRosenwasser]

This PR changes the way in which string literal types work today. It seeks to address some of the major issues brought up in #6167. The basic gist is that all string literals start off with string literal types and are appropriately widened to string at appropriate binding locations. This widening to string occurs when the binding itself is mutable.

A alternative (and competing) approach exists on #6196, where we infer string literal types only at select locations.

Here's a small sample of the current behavior:

const HelloKind = "Hello";   // type: "Hello"
let GoodbyeKind = "Goodbye"; // type: string

const Kind_A = HelloKind; // type: "Hello"
let Kind_B = HelloKind;   // type: string

// type: { name: string; }
const Foo = {
   name: "Foo",
};

interface Bar {
    barProp: "Bar";
}
const myBar: Bar;

// type: "Bar" 
const { barProp } = myBar;

// type: string
const { baz } = {
    baz: "bar"
};

However, when working with a union type of string literals, we won't automatically widen to string even for a mutable binding:

declare function f(): "Foo" | "Bar";

// type: "Foo" | "Bar"
let a = f();

Fundamental changes to string literals and string literal types are:

1. String literal types come in two flavors: fresh and stale (neither is "better" - think day old pizza).
2. Two string literal types with the same content are always equal, regardless of freshess.
3. A string literal _always_ starts off with a fresh string literal type, regardless of contextual typing.

Changes to the widening process are as follows:

1. Variable-like declarations with no type annotations now go through an intermediate mutability-aware widening process.
2. The standard widening process now widens all fresh literal types to string.

Mutability-aware widening is fairly simple:

1. For mutable bindings (like var and let declarations), a singleton literal type is widened to string, regardless of freshness.
2. For immutable bindings (like const declarations):
   1. A string literal type is stripped of freshness.
   2. A union's type's string literal type constituents are stripped of freshness.

Changes to best-common-type selection are as follows:

1. If all constituents are string-like, then the resulting type is string.

[DanielRosenwasser]

This looks kind of untenable to review. I'm gonna rebase this so people can go commit by commit.

[DanielRosenwasser]

I've rebased so there are batches of commits. Here's the order

1. Changes to the type checker.
2. Baseline acceptances for symbols, types, and then error & output files.
3. Addition of new tests.
4. Baseline acceptance of for tests.
5. Correction of fourslash tests.

[JsonFreeman]

What flavor of string literal type does a string type literal introduce?

Does a readonly property initialization strip a string literal of its freshness?

[DanielRosenwasser]

What flavor of string literal type does a string type literal introduce?

Fresh. Thanks for the question, I've amended the issue.

Does a readonly property initialization strip a string literal of its freshness?

At this point I believe that will be the case, but I will need to discuss it with @ahejlsberg.

[DanielRosenwasser]

This was nice to experiment with. 😃