Investigate removing the concept of object allocators

[DanielRosenwasser]

Today we have the concept of an "object allocator". This is basically a set of functions, each which returns a constructor function for a commonly used data structure in the compiler.

/** @internal */
export interface ObjectAllocator {
    getNodeConstructor(): new (kind: SyntaxKind, pos: number, end: number) => Node;
    getTokenConstructor(): new <TKind extends SyntaxKind>(kind: TKind, pos: number, end: number) => Token<TKind>;
    getIdentifierConstructor(): new (kind: SyntaxKind.Identifier, pos: number, end: number) => Identifier;
    getPrivateIdentifierConstructor(): new (kind: SyntaxKind.PrivateIdentifier, pos: number, end: number) => PrivateIdentifier;
    getSourceFileConstructor(): new (kind: SyntaxKind.SourceFile, pos: number, end: number) => SourceFile;
    getSymbolConstructor(): new (flags: SymbolFlags, name: __String) => Symbol;
    getTypeConstructor(): new (checker: TypeChecker, flags: TypeFlags) => Type;
    getSignatureConstructor(): new (checker: TypeChecker, flags: SignatureFlags) => Signature;
    getSourceMapSourceConstructor(): new (fileName: string, text: string, skipTrivia?: (pos: number) => number) => SourceMapSource;
}

Why do this? Because for our batch compiler, TypeScript uses constructors with more bare-bones objects. For the most part, there are no members on the prototype, and we work purely with instance-set data.

On the other hand, the language service and TypeScript's API provides constructors that are attached to richer prototypes. For example, Nodes constructed by the language service have methods like getStart(), getEnd(), getSourceFile(), etc. These are partially for convenience and if my memory serves correctly, partially to power backwards-compatibility going back to TypeScript 1.0's tree API.

However, managing the two is slightly annoying, and creates layers of indirection. It would be nice to see if we can move away from this indirection and whether it can eliminate runtime overhead at all.