maint(common): consider declaring used types/libs in each tsconfig.json

For most of our projects, tsc will implicitly include all `node_modules/@types` type modules in the build. This can cause problems when some of the types depend on e.g. dom. I found this happening when I installed `@types/jquery` and `@types/jqueryui` into a Developer project (see #16520). This caused other projects in web such as predictive-text/wordbreakers to fail to build with a string of nearly 100 errors, e.g.:

```
../../../../../node_modules/@types/jquery/index.d.ts(165,29): error TS2304: Cannot find name 'XMLHttpRequest'.
../../../../../node_modules/@types/jquery/index.d.ts(537,20): error TS2304: Cannot find name 'Element'.
...
```

A resolution for this may be to explicitly declare the list of types imported with the [`"types"` compiler option](https://www.typescriptlang.org/tsconfig/#types). Alternatively, if we want to avoid any implicit import of types for a given module, we could override the [`"typeRoots"` option](https://www.typescriptlang.org/tsconfig/#typeRoots) with `"typeRoots": []`.

Benefits:
* Being explicit about our types helps us to avoid accidentally importing node and/or dom types in modules that should not depend on them.
* We clearly audit our es-version compatibility because we'll need to specify the minimum es version in `lib`, e.g. `"lib": ["es2016"]`
* Setting types and/or typeRoots appears to improve build performance because tsc will no longer load all the myriad `@types/.../index.d.ts` files unless they are actually referenced. I haven't profiled this yet.

Other thoughts:
* https://www.reddit.com/r/typescript/comments/1nsd60m/what_tsconfig_options_beyond_strict_should_i/ is interesting but not directly related
* https://github.com/tsconfig/bases may give ideas

Start by locating the tsconfig.json files for the Developer project and affected web projects such as predictive-text/wordbreakers, then inspect how their compiler options currently handle implicit @types. Compare the proposed types and typeRoots approaches, including the lib setting, and run the affected builds. Done means the chosen configuration is applied consistently and the reported cross-project type errors no longer occur.

Written by the indexing model from the issue text.