Allow users to manage their event attendance from the Codebar website.

At the moment, the only way for a user to manage whether they're coming to Codebar is via email. There's no way for someone to sign up for an event from the website - nor can they remove themselves from the list, or even have an easily-bookmarked page for the details. There's also a lack of detail about what goes on at a meeting. This changeset changes that. 

![Screenshot](https://cloud.githubusercontent.com/assets/244541/5447158/bea9b614-84c1-11e4-89bd-7722237d7f35.png)


- Anyone can see a dedicated page for each workshop.
- Logged out users are encouraged to sign in or sign up
- Logged in users can register to attend as either a student or a coach, join the waiting list if there are no spaces available, or cancel their attendance. 
- There's extensive test coverage.

-------------------

Some key points to review: 
- I've removed one failing test, partially because it doesn't really make sense any more but also because I couldn't figure out how to make it pass. I could be wrong with that decision. 
- We no longer automatically generate an invite email when a `SessionInvitation` is created, as they can now be created (and immediately marked as attending) from the web. I think I updated all the places that use them to explicitly send emails.
- With email invites, users can't update their attendance in the last few hours before an event. Here, they can: users can change their details for any future event. I think this is better, as it means that a human doesn't have to go into the admin panel and manually cancel their attendance (meaning waitlisted people get notified earlier so will have more chance to attend). But if we want to keep it consistent, I'm happy to add the time-gating too. 
- The redirects to the login page aren't smart. They won't take the user back to the workshop page after login. I've got some follow-up work I'd like to do regarding login/signup, and will fix this as part of that. 
- There's opportunities to DRY up the templates, and also to make better use of presenters. 
- The design probably needs work.
This is basically a safety guard for human error. `attending_students`, despite its name, returns `SessionInvitation`s, not `Member`s - but it won't raise an error, and will just return `false`. Which means it's really easy to accidentally pass something in to `attendee?` that returns `false` unexpectedly. The `raise ArgumentError` prevents that, and makes it fail earlier. 

But, `current_user` can be `nil` if someone isn't logged in. That's valid. In which case, it should just return `false` - hence the guard on line 78.