Surveyform roadmap

Some thoughts on the next steps for the `surveyform` app.

### Remove Vulcan.js Dependency

On my 2016 MacBook Pro, each Next.js route can take multiple minutes to recompile whenever something changes. I think this might be in part due to the excessive number of dependencies caused by relying on Vulcan. Also, we use very few of the features that Vulcan provides, and sometimes even go against them.

Vulcan's core feature is arguably the schema system, but because of this we end up having to load all schemas for all surveys all the time, which is not great… Especially now that we've moved all the admin stuff to `surveyadmin`, I think we've reached the point where Vulcan is more of a hindrance than a help. Maybe we can look towards https://zod.dev/ instead

### Remove Mongoose Depencency

Even if using MongoDB directly can be a hassle sometimes, I think we should do it anyway just to remove one more layer that can become a possible source of issues.

### Remove GraphQL

We also don't need GraphQL. We have very simple data loading needs (1. load current user; 2. load a response) so GraphQL seems like overkill. A REST API or maybe tRPC would be a better fit.

### Remove SmartForm

This goes together with removing Vulcan, but I think SmartForm is great when you have tons of simple forms, but sucks when you basically just have one big very customized form, which is our case. Maybe we can look at react-hook-forms.

### Move More Code to `/shared`

I suspect around 30-50% of current code should probably live in the `/shared` directory of the monorepo, especially since `surveyform` and `surveyadmin` are "twin" apps in a way.

### Rethink File Structure

The current file structure is a weird hybrid of feature-driven and role-driven. I think once we've moved more code out of `surveyform` we can adopt a simpler role-driven structure with `/components`, `/server`, etc.

Even after a couple months of working on the codebase I'm still completely lost when looking for a file, so I think we need to rethink this one way or another.

### Rethink CSS Architecture

Current SCSS code has two main problems:

1. it's not scoped
2. it doesn't use CSS variables

I think moving to Sass/CSS modules would be a good solution that we can ultimately apply to other apps as well.

### Get Rid of Webpack

Webpack seems like one of the main things slowing down the app in dev. It would be nice to explore other options.