Figure out Wasp's `tsconfig` story after Wasp 0.12.0

[sodic]

During the restructuring in Wasp 0.12.0, we had plans to optimize how Wasp uses different tsconfig.json files.

Wasp 0.12.0 ended up being a compromise between ease of implementation and DX. Now that 0.12.0 is out, we can focus on optimizing how Wasp uses and interprets tsconfig files.

Here's the original issues for context:

• 1430

Other relevant context:

• https://github.com/wasp-lang/wasp/pull/1584#discussion_r1404336141

TSconfig-related issues that are still relevant after 0.12.0:

• https://github.com/wasp-lang/wasp/issues/1057 (no longer fully applicable, but this comment explains an approach to open questions).
• https://github.com/wasp-lang/wasp/issues/835
• https://github.com/wasp-lang/wasp/issues/939
• https://github.com/wasp-lang/wasp/issues/1718

[sodic]

Project references may help us have users' code compiled with their own tsconfig.json.:

• SDK: SDK includes a full copy of the user's code under node_modules/wasp/ext-src. We can also copy the user's tsconfig.json into node_modules/wasp/ext-src and make mode_modules/wasp/tsconfig.json point to it using a project reference. Possible problem: If parts of the config only work in the file's original location, we'll have a problem after copying it.
• Framework: Framework imports some components from ../../../src directly. We can use a project reference to include the user's tsconfig.json (which should already be applied to everything in src).

Reference: Effective Typescript, 2nd edition, item 78.