Provide clear instructions how to easily test code changes made in waspc/ code

[Martinsos]

Make it so that if somebody wants to make a change to waspc/ code and test it, it is clear how they can easily do it. Couple of days ago I was in this situation and actually it wasn't very clear to me if there is an example app that I can easily run and use or if I have to create my own in order to test this specific feature I was working on.

@sodic then told me that waspc/examples/todoApp is kept up to date with the latest code always, and since it has most of the features in it, that is actually the best way to quickly test the changes! I was kind of aware if has most of the features in it but wasn't aware it is kept up to date, I assumed it would potentially be broken till the actual release. But, it is actually checked in the CI (if it can build) and some e2e tests run over it (not fully tested though, but is somewhat), and that is great. The only tricky part is getting the env vars set up for it, for all the APIs, but we could also look into how to make that as easy as possible.

TODO:

• [x] In README.md (or CONTRIBUTING.md, whatever is the right place) explain that the easiest way to test the code is to use waspc/examples/todoApp, and that it is run and tested in CI, so not only can a contributor use it to test stuff, they should also make sure it keeps working and passing tests. Also provide some guidance here regarding the env vars -> maybe just point them to the README of the todoApp.
• [x] In README.md of a todoApp, explain how one can in the most easiest way get the app running, and what do they need to set up go about it (it will come down to setting up ENV vars mostly). I guess the story will be different for external contributor and for the member of the Wasp team, as inside the Wasp team we can have Google Auth app and others set up and just provide easy way to get the keys on developers machine, while for external contributor we need to advise them on either setting those up or disabling / circumventing them in the fastest / easiest way. Btw @sodic has something that might be helpful here (is it a script? Or a list of env vars or something like that? Check with him).
• [x] When one is about to create a new PR for Wasp on GitHub, there is the checklist of things to take care of (tests, changelog, ...). We should also add that they need to make sure that waspc/examples/todoApp is updated if needed and passing tests.

[sodic]

My setup is described here: https://github.com/wasp-lang/wasp/issues/1883#issuecomment-2069646739

[Martinsos]

A bit of learnings: In CI, we check:

1. That examples/todoApp compiles (both by Wasp and by TS), and that it builds (by Wasp, and then also that generated client/server build further).
2. That headless-test/examples/todoApp passes e2e (playwright) tests.

This makes the situation a bit more complex, since we don't have a single app that we thoroughly test. This is connected to https://github.com/wasp-lang/wasp/issues/2024 -> which says that this should indeed be just one app, and that we will likely keep the one under waspc/examples/todoApp.

Which one is the right one to recommend here then? I guess waspc/examples/todoApp? Even though it is not tested by e2e tests properly.