Always use the user's `tsconfig.json` when processing their code

[sodic]

[!NOTE] This issue is related to #1718 but can be solved independently.

Problem

The user code is currently type-checked and built in four different contexts, each with its own errors and reporting.

See the table or graph below for details.

Context	Configured by	Where it reports errors	When it reports errors
VS Code	/tsconfig.json	Squiggly lines in the IDE	While the user is working on their code
SDK	.wasp/out/sdk/wasp/tsconfig.json	In the terminal, under [Wasp]	While building the SDK during wasp start and wasp build
Server	.wasp/out/server/tsconfig.json	In the terminal, under [Server]	While building the server during wasp build *
Client	.wasp/out/web-app/tsconfig.json	In the terminal, under [Webapp]	While building the client during wasp build *

* I don't think the server and web app do any type-checking during development. See #1718 for details.

Solution

We should explore how to always process the user's code exclusively under the rules specified in their tsconfig.json. This is most likely doable with project references: https://github.com/wasp-lang/wasp/issues/1827#issuecomment-2133815538.

We must do this for all three of our framework's modules (SDK, client, server), and I believe project references are a solution in all three cases.

[Martinsos]

This is some nice, easy to understand analysis, love it! What did you use to make the diagrams?

[sodic]

Users indirectly requesting this (they're requesting simpler imports or tsconfig aliases, but solving this issue is how we make that happen):

• https://discord.com/channels/686873244791210014/1290222832776777778/1290226963922944053
• My friend, when building a movie night app in Wasp, also found the imports confusing.

I recall many similar requests, but we didn't record them. Still, I'm certain that the lack of support for import aliases is a common hurdle.