Turn password resets into a job queue

Closes #4 (closed).

I made this to keep the API consistent, though it might be overkill... This MR can be rejected.

Mostly, when I was still mashing together the implementation, I kept it returning 204 when the user is not found, but 200 on success, and that 200 contained the email job id (for debugging and testing purposes, if the user doesn't get their email, they can give us that ID, and for the tests, they wait on the job to complete before continuing).

This MR can be rejected in favor of returning maybe 404 for unknown users, and 200 w/ job id for success. I think this might be the better option instead of creating another job queue on the database to be managed, etc.

I also noticed that while login receives JID, reset password receives an email, should we worry more about enumeration there? If so, we can go on with this MR. If not, this can be dropped.