Exported types require the lib user to have `"moduleResolution": "nodenext"`

If your library has an exported subpath such that the following `package.json` is generated:
```json
{
"exports": {
"./subpath": {
"import": "./esm/subpath/index.js",
"require": "./script/subpath/index.js",
"types": "./types/subpath/index.d.ts"
}
}
}
```
A user of this lib who is using TS will find that the `"types"` field above will not be used unless they have `"moduleResolution": "nodenext"` or `"moduleResolution": "node16"` in their tsconfig. (In practice this only affects subpaths `require("my-lib/subpath")` because the top-level `"types"` field will be looked up for the main entrypoint.). The issue relates to us specifically because `dnt` forces explicit exports.

Should we open an upstream issue for TypeScript to apply `package.json:exports["./subpath"].types` resolution even for `"moduleResolution": "node"`? The current restriction ~~isn't explicitly~~ is mentioned in https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#packagejson-exports-imports-and-self-referencing, it's categorised under `"nodenext"` support. But I think they'd be open to extending it to `"node"` because it's not breaking in practice.

Otherwise we just have to document the requirement that an npm lib generated with dnt requires the lib user to have `"moduleResolution": "nodenext"` in their tsconfig for subpath imports to be typed.