Add support for transpiling per-file jsx pragmas

[weswigham]

This adds support for per-file jsx factory pragmas (similar to babel):

/** @jsx dom */
import { dom } from "./renderer"
<h></h>

becomes

var renderer_1 = require("./renderer");
renderer_1.dom("h", null);

We still expect the global jsx compiler option to be set and the file extension to be tsx or jsx; but now you can mix multiple jsx frameworks in one project (just not more than one per file). This only affects emit and not typechecking - multiple different frameworks' types attempting to define, eg, JSX.Element can still result in type errors if those definitions conflict.

Fixes #21114, probably?
ref #18131

[uniqueiniquity]

Currently, JSX Fragments emit an error when used when jsxFactory is defined in the compiler options. This may change in the future, but until then you might need additional changes to ensure the error happens when the factory is only defined locally.

[weswigham]

@uniqueiniquity A similar error is now present when a fragment is used alongside an inline jsx pragma. 🌞

[weswigham]

@mhegazy Do you wanna give this a brief look-over before it's merged?

[mhegazy]

add a test with ** @jsx React.createElement */

[mhegazy]

if we gonna add a new concept, then we should consolidate the other ones under pargma.. and we should allow /// as well as multi-line comments.

I would also have helper functions for getting all of these like amdDependecies, amdModuleNAme, checkJs, etc..

[weswigham]

Sure! I wanted to consolidate them, anyway, just didn't think this PR was appropriate.

[sheetalkamat]

We need to ensure this works well when doing incremental parsing as well and need test for the same.

[mhegazy]

why is it jsx and not jsxNamespace like the compiler option?

[weswigham]

Babel supports jsx and I figured we'd want to support the same thing - we can alias jsxNamespace, if you'd like?

[mhegazy]

also add a test with two files, and @jsxNamespace defined, and one of them with the new pragma.

[weswigham]

@mhegazy @sheetalkamat I've unified all pragma-parsing infrastructure such that new pragmas can be added just by editing an object literal, alternate syntaxes enabled, etc - also this PR is much larger now. (And a bit off topic, which is why I wanted to do it later, but w/e, it's here now)

@mhegazy Which old/new pragmas did you want to allow under which syntaxes (XML-like triple slash, singleline @-pragma or multiline @-pragma)? (So I can update their config and add tests of the alternate forms) I imagine we can be permissive and any ones we don't consider legacy we could allow under all the syntaxes we like, so users don't have to remember which syntax we actually parse.

@sheetalkamat I think now that I've unified the implementations, incremental is handled correctly - preProcess.ts is the implementation of re-scanning this data for incremental purposes, right? Now it handles the new pragmas the same way as the old ones (and the same way as the parser, for that matter).

[mhegazy]

why not set this one in processPragmasIntoFields like the other ones, just for consistency.

[weswigham]

It pretty much maps to localJsxFactory, its calculation is just deferred.

[weswigham]

I could move the calculation (and make it eager) from the checker into the parser, if you'd like.