Speed up fourslash tests

[RyanCavanaugh]

This makes two time/correctness tradeoffs that I think are worthwhile. Each saves approximately the same amount of time; on my machine the fourslash suite went from 1m55s to 1m05s

• Use ts.transpile instead of a full compiler setup to compile the fourslash test code into JS. This means we won't see errors per se in the originating fourslash test, but people should be editing these in an editor that provides error highlighting anyway
• Turn off the "high fidelity" typing behavior by default. High fidelity input was never intended to be used everywhere and it invokes a ton of LS calls that are irrelevant and haven't really found any bugs.

[DanielRosenwasser]

Use ts.transpile instead of a full compiler setup to compile the fourslash test code into JS. This means we won't see errors per se in the originating fourslash test, but people should be editing these in an editor that provides error highlighting anyway

This means that if you ever change something in goTo or edit in some way, you'll never know about it because you don't have all of your tests open in your editor. 😕

[RyanCavanaugh]

This means that if you ever change something in goTo or edit in some way,

It's hard to imagine we'd do that?

[weswigham]

We should use transpileModule (seeing as we claim that transpile is pretty much deprecated on the wiki) and reportDiagnostics: true. Just so we report parse errors, since they're going to get hit anyway.