WIP: Application Forms scaffolding

[jaredcwhite]

Addresses #325

I moved the old demo form to /applications/archived/new. The new flow begins at /applications/start/choose-language

Only a few steps in the full flow done so far. BTW, I'm finding it a challenge to ascertain if conditional steps should be handled by state management within a single page, or if we should define each one as a separate page and use the Next router to go between them. I'm leaning towards managing state within a single page as the initial approach, but we can certainly revisit that as time goes on.

Not too concerned with visual fidelity right now. I expect that to be done in a future pass.

[jaredcwhite]

All right, I think this PR is ready for wider attention…I got most of the steps in there (basically just missing some of the intermediate conditional lists). We'll also need to search-and-replace the <h5 className="font-alt-sans text-center mb-5">LISTING</h5> heading on all the pages once we figure out how we're tracking which listing the application is for. The step logic objects in src/forms/applications are only present for the first few steps, but it should be pretty straightforward how to add new ones.

Oh, forgot to mention — the first route is now at /applications/start/choose-language—the demo stuff from before has been archived and we can safely remove soon.

[bk3c]

Two comments that won't block merging, but I want to make sure are out there as we keep growing this going forward:

1. We definitely need to think about the smoothest way to make sure all of the user-facing text is ready for i18n / translations. I know it's still an ongoing discussion of how to handle that with the MDX case, but I'm wondering if we should think about migrating back toward JSON fields now that we've landed MD support there? It seems like the need for actual React components in the MDX is minimal since there's a matching TSX for each step, or am I missing something? If we do go the JSON route, maybe we should consider an application-form.json for these so that general.json doesn't get painfully long? In the long-term future I could also see some of the strings potentially loading from the backend to support editing there like a listing field, but I don't think we're ready for that quite yet.

2. The other thing I definitely anticipate loading from the backend before too long is the configuration that defines which application questions will be asked for any particular listing. For example, some cities will have different versions of questions than others, or some steps will only be applicable to certain types of listings. My thought is that we don't want the front-end to evaluate the listing itself or try and tie a bunch of conditional logic into the form -- instead we want to have a form configuration sent from the backend which drives how the form is displayed, essentially picking from all of the components that the front-end implements. This seems like a good match for the ApplicationConductor as a place to read that kind of config in the future and drive the logic, but if there's a better way to set up for that future then I'm open to that as well. Note: we do not need to actually do everything I just described here now / for the MVP, just be ready for it in the fall without regretting our current decisions.

[jaredcwhite]

1. …wondering if we should think about migrating back toward JSON fields now that we've landed MD support there?

Agreed, I'll take out the MDX sidecar files—that was sort of a holdover approach from the past and I'd prefer to stick with JSON strings and/or future CMS-ish things we might implement.

2. The other thing I definitely anticipate loading from the backend before too long is the configuration that defines which application questions will be asked for any particular listing…This seems like a good match for the ApplicationConductor as a place to read that kind of config in the future and drive the logic

Yep, that makes sense to me. I think it'd be pretty straightforward to conditionally show or hide fields or even change the routing flow based on that particular config.