Improve TypeScript compatibility tests

[timostamm]

Currently, we are testing compatibility with older versions of TypeScript by compiling tests. We want to make sure that the generated code, the runtime library, and common use cases compile without issues with older versions of TypeScript.

Because our tests import from Node.js built-in packages, we need @types/node, which requires different versions for different versions of TS. This introduces complexity (e.g. #574 (comment)), but does not give us any extra confidence.

The best way forward seems to be to add a single file to packages/protobuf-test/src with common use cases, which does not import from Node.js built-in modules and does not import from @jest/globals either. Then compile it with various versions of TS for confidence.

[timostamm]

This is blocking us from upgrading to Jest v30, see #1186 and #1163.

[timostamm]

With TS 5.9+, the TypeScript compatibility tests are no longer sustainable in their current form.

The goal of the tests is to cover the out-of-the-box experience for users with the default compiler settings, and to catch any regressions across supported versions of TypeScript.

Until now, we've got by with a simple trick: We include from packages/protobuf-test/src/. The tests include a whole lot of code that creates, serialize and otherwise interacts with messages and other types. There are also tests exercising various aspects of the generated types, including JSON types.

With TS 5.9, noUncheckedIndexedAccess and exactOptionalPropertyTypes are enabled by default. We've enabled exactOptionalPropertyTypes for all code in this repo in #1371, but we have decided against enabling noUncheckedIndexedAccess for the code base because it doesn't improve the code quality.

TS 5.9 also sets types: [] by default, which means our test files (which import from Node.js built-in packages) no longer compile with the defaults.

This means that our code base is diverging from the compiler settings we need to test going forward. Seems like the original issue description still holds true:

The best way forward seems to be to add a single file to packages/protobuf-test/src with common use cases, which does not import from Node.js built-in modules [...]. Then compile it with various versions of TS for confidence.