Rework account creation flow

[RobinsonZ]

The current account creation flow (fill out form -> human approves -> account is created) is unintuitive and not very fun for users, annoying for staff, and introduces some significant security holes. Namely:

• We don't verify the existence of a user's Swarthmore email or any information about them until sending the password reset email, making it very possible that a "phantom" account can get created with an email that isn't valid; this is partly a security hole but mostly a UX issue since it's pretty easy to mistype an email
• Staff tend to rubber-stamp account creation requests, so it's definitely possible that someone could register as a class year they aren't, name that isn't the person who controls that email, etc.

This issue is to track progress on creating an alternative account creation flow that goes something like this:

1. User enters their Swarthmore email on a "create account" page
2. SAUCE sends them a verification email with a link that takes them to a "set up your new account" page. If the user exists in the ITS database that we use for Cygnet, then we pre-populate their name and class year from the database. However, people's preferred names often differ from the name Swarthmore has on file, so we give them the option to change the pre-populated info. (Also, since faculty and staff don't exist in Cygnet either, we'll need to ask them to fill out all of their info.)
3. If the user is fine with the Cygnet-populated info, we immediately create the account, let them set their password, and log into their account with no staff approval needed.
4. If the user wants to make a change from their Cygnet information (or have no pre-populated values), SAUCE sends these changes to the task queue for approval. We present to reviewers both the Cygnet info and requested info.
5. After task queue approval, we fully create the account and send a password reset. (In the rare case that a staff member decides to deny the creation request they should reach out to the person individually to follow up.)

Minor implementation notes:

• Since students might not be in the ITS database for some reason, we can't assume that emails without a database entry are faculty/staff: we'll still need to give them the option to choose a current class year.
• The language on the user-facing end of the diff page should emphasize that diff requests are common and usually approved very quickly.

[adic2023]

Make new endpoints for page with just email account creation
new page with data from cygnet asking if changes are necessary