• When tsconfig specifies compiler options incremental file with .tsbuildinfo extension is emitted.
• Composite projects indirectly specify incremental as true and its error to specify incremental as false in the composite project
• If project specifies tsBuildInfoFile options, it uses the path specified by that to write the build information.
• If project specifies out or outFile option, the outFileWithoutExtension.tsbuildinfo file is written next to output js file.
• If project specified outDir, config files base file name with extension as .tsbuildinfo is written in outDir
• Otherswise config files base file name with extension as .tsbuildinfo is written next to the config file
• Generated file is json with type as BuildInfo shown below.

    export interface SourceFileInfo {
        // List of helpers in own source files emitted if no prepend is present
        helpers?: string[];
        prologues?: SourceFilePrologueInfo[];
    }

    export interface BundleFileInfo {
        sections: BundleFileSection[];
        sources?: SourceFileInfo;
    }

    export interface BundleBuildInfo {
        js?: BundleFileInfo;
        dts?: BundleFileInfo;
        commonSourceDirectory: string;
        sourceFiles: ReadonlyArray<string>;
    }

    export interface ProgramBuildInfo {
        fileInfos: MapLike<BuilderState.FileInfo>;
        options: CompilerOptions;
        referencedMap?: MapLike<string[]>;
        exportedModulesMap?: MapLike<string[]>;
        semanticDiagnosticsPerFile?: string[];
    }

    export interface BuildInfo {
        bundle?: BundleBuildInfo;
        program?: ProgramBuildInfo;
        version: string;
    }

• Field program in buildInfo is Builder information so we can track the file changes since that version and build incrementally even without watch (that is emitting only affected files or getting errors only from changed/affected files). This should help us get perf similar to --w incremental builds even on subsequent invokes of build (In short we are serializing information of builder program that we keep in memory during incremental builds in --w mode). Also pulled 6c5ae93 to store semantic diagnostics though in --b scenario it will always be just file name as emit happens only if there are no errors.
• Field bundle stores information to be able to emit into single file. This consists of different sections in file, eg. prologues, prepended file contents and their range's. When having project that references another project with prepend as true, this helps in faster emit when the referenced project changes but it doesn't change declaration file. Previously we would have to create program for project referencing changed output to generate new output, but this just uses section information from buildinfo file and emit new output without having to create program. This saves us time for creating program and checking errors (since the errors are not cached with --out as we cant tell change in declaration emit) and emitting all files. Having section also fixes issues like Duplicate "use strict" prologue in the generated output.  #25550 to generate better output.
• if version of compiler does not match with version in the buildInfo file, it starts fresh build
• The bundle information also contains internal declaration sections, so if project has stripInternal instead of concatenating whole string it skips out portions of internal and generates correct .d.ts
• Currently the build info is generated and emitted in emitter but the information comes from two places, emitter itself (about --out) and the other from the program itself which is actually builder program (so one level of abstraction outside of the program). Open to suggestion if there is different way to write this information. Goal was to not write files multiple time (eg once by builder and once by emitter). Also another thought is that builder doesn't do anything or change much if the scenario is --out since any change means new emit and new diagnostics, so its ok to not store program information in this case and in other scenario there is nothing of importance in those other section than program so may be separating these two (reading and writing only modified field) might not be a bad decision. But will need to see how that goes.

Measured perf with updating LKG from master to build this branch using gulp local and then with this branch's build as LKG and using gulp local