TypeScript: add typeRoots to tsconfig

[karlvr]

This avoids typescript looking in parent directories to find type definitions. We don’t need this behaviour from typescript, as this module is self-contained. If we don’t block this behaviour from typescript, and you put the generated source inside a project that already has a node_modules/@types directory, you can run into conflicts when some types require newer versions of TypeScript than is used by this module.

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh, ./bin/security/{LANG}-petstore.sh and ./bin/openapi3/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

Fixes #2394 by adding typeRoots to the generated tsconfig.json file.

This avoids typescript looking in parent directories to find type definitions. We don’t need this behaviour from typescript, as this module is self-contained. If we don’t block this behaviour from typescript, and you put the generated source inside a project that already has a node_modules/@types directory, you can run into conflicts when some types require newer versions of TypeScript than is used by this module.

/cc @TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny @nicokoenig @topce

[macjohnny]

LGTM

[macjohnny]

the failing shippable test doesn't seem related to this PR, so I think this should be good to go

[wing328]

Restarted the shippable job and the tests passed.