Add emitter scaffolding

[rbuckton]

This adds Program.Emit() and the basic scaffolding for the emitter. At present, this only performs printback of the input source file as output transformation has not yet been implemented.

This also adds an --outDir DIR option to tsgo.exe to verify emit. When not specified, tsgo.exe will not trigger emit.

In addition, this fixes a bug in getLinesBetweenPositions that incorrectly caused the printer to print excess newlines.

[EricCornelson]

The program parts look pretty good to me. The only thing that gave me pause was whether or not Emit should live in emitter or program, but I don't think it's a big deal either way

[rbuckton]

The program parts look pretty good to me. The only thing that gave me pause was whether or not Emit should live in emitter or program, but I don't think it's a big deal either way

I've moved it to program.go. I kept it separate mostly to avoid any potentially messy merge conflicts as I'd started this before #107 had merged.

[jakebailey]

Can we get away with not normalizing again? I think all callers are normalized.

(I would really like to explore using a named NormalizedPath or something to avoid extra work...)

[rbuckton]

There's no guarantee the path is normalized, just as there's no guarantee the path is rooted (which is why this and other methods validate the path is rooted). We also call NormalizePath for other VFS methods, though it's buried in splitPath/rootAndPath, so it makes sense to remain consistent.

[jakebailey]

Are we ever going to have more than one implementation of this?

[rbuckton]

I'm not 100% certain yet. This was something we allowed users to override when consuming the API, so that all depends on our long term API story (as in, could someone build on top of our go package). I opted to leave it as-is to more faithfully port portions of the emitter.

[jakebailey]

I think this looks good, but once last thing to check; since our program construction is more or less fake right now, where we just walk a dir and find all ts/tsx files, will this end up emitting files we shouldn't? I assume so, which can be fine, but we're going to start loading lib.d.ts files and those shouldn't be emitted for our testing, I would think.

[rbuckton]

It won't generate emit for .d.ts input files at present, and only emits if you specify --outdir, so the risk is fairly low.

[jakebailey]

Yeah, that seems fine, then. I was just thinking of random .ts files that happen to appear within someone's project, but if we're ignoring .d.ts files for our basic use right now, I think that's plenty given most projects will have some sort of src dir we can run on, like vscode or TS itself.

[jakebailey]

I just ran this; this needs to be something like:

Suggested change

	compilerOptions.OutDir = outDir
	compilerOptions.OutDir = tspath.ResolvePath(currentDirectory, outDir)

Otherwise I get:

panic: vfs: path "wow/src/vs/platform/utilityProcess/common/utilityProcessWorkerService.js" is not absolute

(so, probably move down below)

[jakebailey]

Interestingly since we currently include .js files for vscode (due to missing node types), I get:

├── node_modules
│   ├── events
│   │   └── events.js
│   ├── string_decoder
│   │   └── lib
│   │       └── string_decoder.js
│   └── util
│       └── util.js
└── src
    ├── bootstrap-cli.js
    ├── bootstrap-esm.js
    ├── bootstrap-fork.js
    ├── bootstrap-import.js
    ├── bootstrap-meta.js

[rbuckton]

Excluding Node_modules is one of the as-yet unimplemented branches