Fix @tsconfig/bases implicit config logic so old TS versions won't get an incompatible config

[cspotcode]

breaking changes to newer @tsconfig/bases

The latest @tsconfig/bases use module node16, for example: https://github.com/tsconfig/bases/blob/main/bases/node14.json

node16/nodenext was added in TS 4.7

We still support as low as TS 4.4, because we match DefinitelyTyped's support window

Our implicit config logic already rejects tsconfigs that your TS version does not support, but it only falls back so far, returning the node14 config by default.

We need to go a step further, falling back to no implicit config if none of the @tsconfig/bases are compatible. Note that the user controls which version of @tsconfig/bases they install, so if their project has an older revision of a @tsconfig/bases installed, and it is compatible with their TS version, then they'll get it by default.

We also need to add logic to fallback when module and moduleResolution options are incompatible

Broken tests

When we fallback to no implicit tsconfig, other test cases break. They were relying on an implicit @tsconfig/node14 setting a relatively high target and module: node or similar.

To avoid this and still have reasonable test coverage:

• Add TS 4.7 to the test matrix
• tweak implicit tsconfig tests
  • make them run conditionally if ts supporting node16
• tweak useDefineForClassFields tests
  • manually specify module option so they're not affected by implicit config
  • make es2022 cases run conditionally if ts supports es2022