test: add TypeScript module specs to examples

[ajvincent]

This is to show existing support for TypeScript modules.

Summary

Per #3954, I'm adding example specs with the .mts extension.

This is based on ts-jest's documentation and existing code.

Test plan

npm run test-examples

I manually inspected to confirm each of the configuration files this PR touches runs two different spec files: the existing one and the new TypeScript module file.

Does this PR introduce a breaking change?

• Yes
• No

Other information

Questions on this patch for reviewers, because I'm unfamiliar with this code base:

1. Should the transform value always be ['ts-jest', ...]? The type definition says it could be TransformerConfig, which is just [string, ...]. I am specifically asking because it differs from the preset field in most of these changes.
2. There's a big Caution about mixing preset and transform in the documentation. I see some of these examples already do this, but I'm making it happen here across all of them. What's the right way to handle this?
3. Help wanted with the react-app example. I tried to update it, but I'm almost as new to React as I am to this project. It was too complex for me to quickly figure out. So I left it alone...
4. I figured out most of the mjsResolver's type. When I tried to include it in the TypeScript file, jest-resolve gave me many errors. I tried adding a .d.ts file (which led to linting errors), and renaming it to .mts. Finally, I just put it in as a void string expression, which is a Dirty Hack. I'd like a better fix, so that we can do proper type checking on the resolver. As code documentation, though, it's better than nothing.

[coveralls]

Pull Request Test Coverage Report for Build 3865352927

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.2%) to 95.853%

---

Totals
Change from base Build 3863777653:	-0.2%
Covered Lines:	4055
Relevant Lines:	4154

---

💛 - Coveralls

[thw0rted]

I noticed that none of these examples have been updated to use module / moduleResolution values of NodeNext. NodeNext requires extensions when specifying relative paths, e.g. import {foo} from './foo.mjs' resolving to the file foo.mts on disk. I don't see that happening anywhere here, and I think it might be part of the problem I'm trying to solve in my own project.