Various small DX improvements

As I'm working on the codebase, a couple notes of stuff we could improve to discuss later.

- [ ] We should get rid of all the `.eslintrc`, `.prettierrc`, etc. files to ensure every project follows the same formatting guidelines; and ideally also find a way to make sure every subdirectory uses a similar `tsconfig.json`
- [ ] Except for really simple or single-use helper functions, I prefer using a singleton argument for functions (`const f = ({ arg1, arg2 }) => ...` instead of `const f = (arg1, arg2) => ...` because it avoids any risk of messing up the order of the arguments. Maybe we can start applying that pattern throughout the whole monorepo?
- [ ] We need to make sure we use the same types throughout the monorepo. We have a few duplicates for the same kind of objects currently.
- [x] I still haven't managed to import shared runtime code in the `api2` project.
- [ ] We should decide once and for all where each app loads its data from. For me the source of truth is the GraphQL API, or if that's too slow the same API data cached in Redis. Only the API should talk to GitHub or load files from the filesystem.
- [ ] Still not super happy with how env variables are managed, especially since all the projects share the same ones. But I don't have a great solution…
- [ ] We need to make sure that `/surveyform` uses `surveyId` and `editionId` when saving new responses.
- [ ] Current `responses` document follow a `js2021__features__nullish_coalescing__experience` naming pattern due to the fact that we only had a single schema for all surveys, and wanted to avoid naming collisions. Could we drop this requirement and just have e.g. `nullish_coalescing__experience` now? (at least we should get rid of the `__experience` suffix which should be replaced by looking up the proper template object corresponding to the question)
- [ ] we can probably simplify `surveyadmin` a lot since we don't really need any of the Vulcan models/permissions/forms/etc. It would work better as a "normal" Next.js/Node app I think, closer to `api` but with the admin GUI part added.