PrivateName does not permit escape characters

[DanielRosenwasser]

Discovered by @amcasey while running TS on test262.

export class IdentifierNameWithEscape {
    \u{78}: number;

    constructor() {
        this.\u{78} = 0;
    }

    doThing() {
        this.x = 42;
    }
}

export class PrivateIdentifierWithEscape {
    #\u{78}: number;

    constructor() {
        this.#\u{78} = 0;
    }

    doThing() {
        this.#x = 42;
    }
}

Currently IdentifierNameWithEscape parses and type-checks correctly; however, PrivateIdentifierWithEscape does not even parse.

[DanielRosenwasser]

Another thing to check

class IdentifierNameWithEscape {
    x\u{78}: number;

    constructor() {
        this.x\u{78} = 0;
    }

    doThing() {
        this.xx = 42;
    }
}

class PrivateIdentifierWithEscape {
    #x\u{78}: number;

    constructor() {
        this.#x\u{78} = 0;
    }

    doThing() {
        this.#xx = 42;
    }
}

The first case works perfectly. The second case correctly resolves this.#x\u{78}, but not this.#xx even though they're really the same.

[DanielRosenwasser]

Here are the problems to be solved:

1. The scanner doesn't know that a \ can follow a #. That is sort of easy to fix.
2. The parser asks for the literal text of the token in source, as opposed to the "cooked" character values. This is wrong, and means that unless you wrote you private identifiers the same way throughout, they won't ever be looked up to the same symbol. Fixing that naively, for some reason, seems to cause a lot of test issues and I'm not sure why.
3. An extended escape is an ES2015-specific feature, and for some reason we make the scanner act differently instead of parsing and issuing a span. Fixing the behavior is awkward because it may differ between ES5 and ES2015+.

[fatcerberus]

Why are these escapes even a thing? They're like a modernized version of C/C++ trigraphs...

[DanielRosenwasser]

I'm going to guess that auto-generated code was the use-case, and then extended escape sequences were added for parity.