Set up modular tsconfig projects

[samreid]

From #1047 and related to #1052. For modularity and faster builds, we should set up composite: true for tsconfig project references. Due to complications in #1052, this will not be straightforward, since our dependencies are not well-layered. Until we have good progress in #1052, we can accommodate this by:

• choosing file sets in tsconfig files
• moving testing to a secondary layer (since it brings in many outside dependencies)

The natural way to investigate this would be to put one tsconfig per repo, however I am reluctant to do this in master because this may change the way WebStorm deals with the files. Putting all of the tsconfigs in chipper (which is already branched) sounds nice, but when I tried that I received this error:

~/apache-document-root/main/chipper$ tsc --build --project tsconfig-tandem.json
error TS5094: Compiler option '--project' may not be used with '--build'.

For this same reason, it won't be possible to put tsconfig-test.json in the same directory--we will have to have a top-level test config file in another directory.

It sounds like a lot of overhead, but I don't see better options for exploring this than to create a branch for each repo that wants a tsconfig.json file.

UPDATE: We could put a tsconfig/ directory in chipper, with one directory per repo? There will be a cost when we move these files to repos, but we can avoid all the branches. Maybe I should try that first.

[samreid]

Putting the tsconfig files in separate subdirectories is working well, I have projects set up through scenery. Scenery incremental builds (a change in Node API) are an order of magnitude faster than the "all common code in one project" approach. Note this means tsc -b in scenery is fast, but when building a compilation unit with downstream usages of scenery, that time will need to be included (since they need to be recompiled).

[samreid]

I created tsconfig projects for all runnables and their dependencies, and it seems to be working well. Compile times are significantly improved over the monolithic approach. Here are some remaining clean-up steps:

Common code test files aren't yet in any compilation unit (since tests pull in downstream dependencies)
shred shouldn't pull from build an atom strings
fractions-common needs vegas (not listed in phetLibs)
density-buoyancy-common needs mobius (not listed in phetLibs)

Other oddities are noted in the tsconfig files (mostly common code repos) before c36d1d9

[samreid]

I moved tsconfig files to their respective directories in #1070. There are still several oddities in these files in order to set up a dependency graph. For instance, check out what scenery's tsconfig.json includes:

  "include": [
    "js/**/*",
    "../utterance-queue/js/**/*",
    "../sun/js/SunConstants.js",
    "../sun/js/sun.js",
    "../phetcommon/js/util/StringUtils.js",
    "../phetcommon/js/view/ModelViewTransform2.js",
    "../phetcommon/js/phetcommon.js"
  ],

I'm not sure if this issue should remain open for making that aspect more modular. The other problem about test cases is addressed in #1088

[samreid]

Each repo has a modular tsconfig file, and we have an "all" file. Loose ends of #1088 and #1052 will be handled separately. Closing.