Add passwordless for authentication

[esmale]

What does this PR do?

I've added two gems to the application: passwordless for authentication, and letter_opener in order to easily trigger/access emails in development, since passwordless authentication relies upon email. I hope the application is set up with some kind of email delivery service to actually send emails. :-)

Instead of removing the Speaker model/table completely the way I initially intended while working on this at RailsConf, I backed away from that and just created the User model with an email address, and then set up the Speaker model to belong to a User. I assume that in the admin section of the site you'd be able to associate new User records to old Speaker records as necessary.

The ability to add Speakers has been removed, and instead when a person registers to join the site they also have to give their name, and the controller will create both the User and Speaker records and tie them together.

The ability to add new Proposals is also adjusted:

• You no longer specify the speaker, it's always assumed to be the currently logged in user
• The ability to edit proposals is limited to the proposals that you (the currently logged in user) own

I also removed the need to complete the captcha for these two actions. Since these actions cannot be performed unless logged in, it felt unnecessary. But I haven't removed the gem from the Gemfile yet, in case I'm wrong.

I've added and updated the test suite to account for a lot of these changes, but there are still some tests and application code changes that need to be made before this PR is truly complete. Primarily in the area of limiting the ability for updating Submissions to only the owner of the associated Proposal.

That said, I felt like this PR was far enough along that I wanted to get it in front of you to see what feedback you had.

I also had a could of questions about some corner cases to see what you would like:

1. Should the ability to create Events also be locked behind being logged in?
2. What do you think about putting the captcha on the login and registration forms?

Why was this work done? Is there a related Issue?

This PR addresses this issue: Speakerline is completely open to edit

Where should a reviewer start?

Are there any manual testing steps?

---

Screenshots

Deployment instructions

Database changes

There are a couple of new migrations that add:

• a new users table
• a new passwordless_sessions table
• adds a user_id column to the speakers table

New ENV variables